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Abstract 


The  objective  of  this  project  is  to  design  and  build  a  ball-throwing  robotic  arm  for 
the  purpose  of  high  school  visits.  When  taken  to  local  high  school  physics  classes,  this 
ball-throwing  arm  experience  will  present  college  bound  high  school  students  with  a 
series  of  activities  that  will  allow  them  to  interact  with  typical  challenges  found  m 
Physics,  Mechanical  Engineering,  Electrical  Engineering,  and  Computer  Science. 
Stimulating  interest  and  understanding  of  engineering  challenges  amongst  younger 
students  is  critical  in  helping  them  make  informed  decisions  affecting  future  careers  in 
engineering.  The  key  challenges  in  this  project  include:  1)  designing  an  appropriate 
robotic  arm;  2)  building  it;  3)  creating  a  computer  implemented  control  system  which  can 
converge  two  positions  and  two  velocities  at  a  pre-specified  instant  in  time;  and  4) 
preparing  exciting  interactive  presentations  and  support  materials  that  will  effectively 
educate  high  school  students  about  their  career  interests. 
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1  Introduction 


1.1  Motivation 

Stimulating  interest  and  understanding  of  engineering  challenges  amongst  high 
school  students  is  critical  in  helping  them  make  informed  decisions  about  pursuing 
careers  in  engineering.  The  objective  of  this  project  is  to  present  the  students  with  a 
series  of  activities  that  would  introduce  them  to  typical  challenges  found  in  Mechanical 
Engineering,  Electrical  Engineering,  and  Computer  Science.  These  activities  are  based 
on  a  robotic  arm  designed  to  throw  a  ball  at  a  specific  target.  The  students  will  learn 
about  measurement  techniques,  particle  kinematics,  robotics  and  teamwork. 

The  students  will  first  learn  about  a  ball  traveling  through  the  air  via  tutorials  on 
particle  kinematics  that  will  be  presented  in  their  physics  class.  This  knowledge  will  then 
be  used  to  determine  what  initial  velocities  are  required  to  throw  the  ball  at  a  series  of 
targets.  A  representative  from  the  University  of  Utah  will  then  visit  the  class  and  bring  a 
self-contained  ball-throwing  robot.  The  representative  will  illustrate  the  tasks  faced  by 
the  engineering  disciplines  while  explaining  the  robot’s  design,  electrical  and  mechanical 
systems,  micro-controller,  and  performance  limitations.  The  student  teams  will  then 
setup  targets  throughout  their  classroom,  measure  the  distances  to  the  targets  from  the 
robot,  and  calculate  appropriate  ball  speeds  and  trajectories  considering  the  robot 
limitations  and  room  dimensions.  Each  team  will  then  program  their  results  into  the 
robot  and  see  if  they  can  hit  the  targets.  By  awarding  points  for  accuracy  and  creativity, 
such  as  an  off-the-wall  shot,  a  fun  and  competitive  environment  would  be  encouraged. 

The  main  focus  of  this  project  is  to  present  a  fun  and  exciting  example  of 
engineering.  Through  a  basic  physics  lesson,  the  students  will  use  their  engineering  skills 
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to  solve  a  real  problem  and  have  the  unique  hands-on  opportunity  to  test  their  results  on  a 
robotic  system.  This  should  provide  the  potential  engineers  with  a  glimpse  of  the 
exciting  challenges  that  engineers  face  and  help  them  make  educated  career  choices. 

1 .2  Objectives  for  my  Master’ s  of  Engineering  Degree 

My  project  is  to  build  a  robot  that  can  fill  such  a  role.  The  objectives  for  the 
interactive  presentation  set  the  minimum  capabilities  of  the  robot.  The  robot  must  be 
capable  of  throwing  a  ball  to  any  commanded  position  in  the  room.  This  implies  motors 
with  a  specific  performance  range,  a  computer  controller  capable  of  converging  two 
positions  and  two  velocities  simultaneously,  and  hardware  designed  to  be  accurate,  long 
lasting  and  easily  transportable.  These  various  objectives  each  influenced  the  design  of 
the  robot  in  a  different  way. 

Obviously  setting  such  expectations  early  on  in  the  course  of  this  degree  set  the 
tone  of  the  coursework  taken.  Each  class  had  the  purpose  of  teaching  skills  essential  to 
the  completion  of  this  project.  The  courses  taken  with  this  purpose  in  mind  included: 


Table  1  Class 

Schedule 

Class  Description 

Class  Number 

Credit  Hours 

ME  EN  Advanced  Control  Systems 

6200 

3.0 

ME  EN  Robotics 

6220 

3.0 

ME  EN  Optimal  Controls 

7210 

3.0 

PHYCS  Electronics  I 

5610 

4.0 

PHYCS  Electronics  I  Lab 

5610 

0.0 

ME  EN  Compensator  Design 

6210 

3.0 

ME  EN  Intermediate  Dynamics 

6410 

3.0 

ME  EN  Nonlinear  Controls 

7200 

3.0 

PHYCS  Electronics  II 

6620 

4.0 

PHYCS  Electronics  II  Lab 

6620 

0.0 

ME  EN  Special  Project 

6970 

4.0 
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1 .3  Structure  of  Paper 

This  project  report  is  written  to  a  level  that  will  be  instructive  to  high  school 
students.  Obviously  many  of  the  modeling  and  controls  details  are  beyond  the  scope  of 
high  school  physics  and  this  paper  cannot  provide  sufficient  background  to  fully  explain 
these  tools.  However,  this  report  is  intended  to  fulfill  two  roles,  one  as  a  source  of 
information  for  students  and  secondly  as  a  project  report  and  technical  background  to  the 
robot. 

The  report  begins  by  explaining  the  objectives  and  some  of  the  background  in  the 
subject.  The  remaining  portion  tells  the  story  of  the  robot’s  development,  starting  with 
the  design,  explaining  many  of  the  reasons  certain  design  characteristics  were  chosen. 
Once  construction  and  assembly  has  taken  place  it  then  outlines  the  controller 
prototyping  and  testing  of  the  system. 
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2  Ball-Throwing  Activity 

The  whole  purpose  of  this  entire  project  is  to  interact  with  potential  students  in  an 
exciting  way,  inform  them  about  engineering  careers  and  guide  those  with  interest  into 
engineering  programs  at  the  University  of  Utah.  In  order  for  the  students  to  have  the  best 
experience  they  need  to  have  enough  background  to  be  proficient  in  the  skills  needed  for 
the  activity  and  the  activity  needs  to  challenge  them  in  a  way  not  usually  done.  This 
section  outlines  the  envisioned  Ball-Throwing  Robot  experience  from  start  to  finish  as 
illustrated  in  Figure  1. 

When  a  potential  class  has  been  identified,  a  University  of  Utah  representative  will 
contact  the  teacher  and  discuss  the  skills  needed  by  the  students  to  participate.  An 
information  packet  will  have  been  prepared,  which  outlines  the  necessary  skills  from  start 


Teacher  Presents  Prep  Lessons 


Web  Page  Shows 
Example  Calcuiations 


Highlight  Robot  Features: 

Position  Sensing 

-  Computer  /  Hardware 
Interface 

-  Power  Source  &  Amplifier 

-  Mechanical  Structure 


Homework 

Students  pick 
targets  and 
calculate  initial 
velocities 


-  Review  /  Summarize  Ballistic  Trajectories 

-  Run  Demo 

i  -  Evaluate  Student  Calc's 

-  Explain  Possible  Errors  and  Show  Correct  Methods 


¥caiii  Campctitiani 


Discussion 


Robot  Design  Includes  Many  Different  Disciplines 

-  Physics  &  Mathematics  Foundation 

-  Mechanical  Engineering 

-  Electrical  Engineering 

-  Computer  Science 


Figure  1  Flow  Chart  Describing  the  Course  of  the  Demonstration 
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to  finish  and  has  pre-worked  examples,  which  give  examples  of  all  basic  situations 
encountered.  The  teacher  will  either  teach  or  review  the  material  to  make  certain  that  the 
students  understand  the  subject  matter.  For  the  students’  homework  the  teacher  would 
assign  the  task  of  setting  out  target  locations  around  the  room  and  calculating  the 
appropriate  robot  commands  -  base  angle  and  release  velocity  -  needed  to  hit  their  target. 
A  web-site  will  also  contain  instructive  material,  showing  how  to  get  the  best  success 
with  the  robot,  discussing  how  release  angle  affects  motor  saturation  or  how  arrival  angle 
influences  the  probability  of  a  direct  hit.  The  web  site  could  also  handle  extra  credit 
problems  like  how  to  bounce  off  the  floor  or  a  wall  and  hit  a  target. 

The  next  stage  of  the  experience  will  be  the  actual  visit,  when  the  U  of  U 
representatives  bring  the  robot  to  the  school.  The  representative  will  point  out  various 
features  of  the  robot  and  briefly  explain  how  it  works,  highlighting  design  issues,  which 
may  be  discussed  further,  in  the  end  of  the  demonstration.  In  order  to  validate  the  robot’s 
ability,  the  U  of  U  representative  will  demonstrate  a  successful  ball-throwing  sequence  or 
series  of  sequences.  At  this  point  the  student  solutions  will  be  evaluated  for  accuracy. 
Then  comes  the  competition. 

The  students  will  divide  into  teams  and  compete  against  each  other  for  accuracy  and 
difficulty.  They  will  need  to  measure  the  distances  to  the  targets  and  calculate  the  release 
velocities  and  angles.  Extra  points  will  be  given  to  the  team  that  gets  the  answer  fastest 
only  if  their  throw  is  successful.  If  two  robots  are  available  for  a  single  demonstration, 
then  the  students  can  compete  in  time  for  the  same  targets.  Furthermore  extra  points  will 
be  given  for  teams  that  incorporate  a  bounce  into  their  throw  or  use  a  lightweight  ball  and 
successfully  account  for  aerodynamic  drag. 
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The  final  phase  of  the  demonstration  follows  the  competition  and  involves  a  more  in 
depth  discussion  of  what  makes  the  robot  work.  The  discussion  will  explain  how 
different  engineering  disciplines  work  together  to  create  something  like  this  robot.  The 
representative  could  explain  that: 

-  a  mechanical  engineer  would  be  involved  in  design  of  the  robot,  modeling  of  its 
dynamics  and  control  of  its  movements; 

a  computer  scientist  would  be  involved  in  creating  the  user  interface,  the 
simulation  programs,  and  the  controlling  programs  which  implement  the 
algorithms  the  mechanical  engineer  designs;  and 

-  an  electrical  engineer  is  concerned  with  interfacing  the  computer  controller  with 
the  actual  robot  without  frying  any  chips,  making  sure  the  power  source, 
amplifiers,  encoders  and  computer  are  all  communicating  properly  and  making 
sure  no  one  gets  hurt  by  the  electrical  components  of  the  robot. 

This  discussion  should  be  one  focused  on  getting  the  students  to  talk,  ask  questions  and 
learn  what  each  different  field  contributes  to  engineering  projects,  such  that  the 
components  can  work  together  as  a  whole. 

The  classroom  discussion  will  be  limited  on  time  and  won’t  be  able  to  explain  all 
of  the  various  aspects  in  depth.  Material  explaining  how  the  robot  works  will  also  be 
placed  on  the  web  site  for  students  to  access  and  learn  more  about  the  various  aspects  of 
its  design,  construction  and  operation. 
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3  Background 

A  survey  of  similar  projects  uncovers  many  projects  involving  common  threads, 
but  different  objectives.  There  are  many  robots  in  the  literature  that  throw  objects,  using 
various  throwing  movements.  They  span  a  broad  range  of  type  and  purpose.  The 
simplest  start  as  single  degree  of  freedom  throwing  robots  built  both  commercially  and 
for  research  purposes.  The  next  common  category  is  the  two-link  category,  which 
includes  traditional  rigid  planar  pairs  and  flexible  member  manipulators.  Many  robots 
have  more  degrees  of  freedom  and  have  been  built  to  catch  as  well  as  throw  balls  and 
even  juggle  multiple  balls.  The  juggling  robots  encompass  their  own  group,  varying 
broadly  in  approach  and  form.  The  ideas  encompassed  in  these  differing  projects  do 
encounter  similar  challenges  in  implementation. 

Michael  J.  Northrop  of  Northwestern  University  [1]  uses  a  one-link  robot  to  feed 
parts  in  an  assembly  line  by  throwing  them  and  manipulating  their  landing  position  and 
orientation.  Once  the  part  is  identified  and  the  trajectory  planned,  then  the  motor  must 
execute  the  command  precisely. 

Eric  W.  Aboaf  [2]  of  MIT  explored  the  advantage  of  task-level  control  when 
throwing  balls  with  a  one-link  robot.  The  system  uses  a  vision  system  to  measure  the 
ball’s  actual  landing  position,  which  can  then  be  compared  against  the  desired  landing 
position.  They  explored  two  methods  of  using  this  error  to  improve  performance.  Their 
Fixed-Model  method  learns  by  applying  an  inverse  model  to  the  result.  Their  Refined 
Model  procedure  manipulates  both  the  model  and  the  command  signal  to  get  the  desired 
results.  It  would  be  interesting  to  build  a  self-monitoring  and  correcting  system  into  this 
robot. 
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Norihiko  Kato  [3]  of  Mie  University  in  Japan  explores  the  control  of  a  two-link 
planar  pair  robot.  He  implements  an  adaptive  non-linear  controller  that  modifies  the 
release  time.  He  shows  improved  results  through  release  time  manipulation. 

The  Ball-Throwing  Robot  shares  objectives  and  requirements  with  each  of  these 
projects.  One  feature  not  shared  is  that  the  Ball-Throwing  Robot  has  a  goal  of 
converging  two  positions  and  two  velocities  at  one  fixed  point  in  space  and  time.  The 
others  are  flexible  in  their  release  and  catching  points.  The  control  and  implementation 
strategies  of  each  project  mentioned  are  adapted  specifically  to  its  purpose.  Similarly 
each  of  these  provides  hints  to  accomplish  these  specific  objectives,  but  none  are 
identical. 
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4  Robot  Mechanical  Structure 


4.1  General  Format 

The  Ball-Throwing  Robotic  Arm  is  a  three-link  manipulator,  depicted  in  Figure  2. 
It  has  two  axes  of  shoulder  rotation,  an  elbow  and  a  simple  open-close  two-fingered  end 
effector  or  hand.  This  configuration  was  chosen  because  of  the  constraints  implied  by  the 
objectives  of  the  demonstration:  a  fixed  release  point;  a  large  range  of  release  velocities; 
and  a  quick  releasing  hand  mechanism. 

The  purpose  of  this  robot  is  to  interact  with  high  school  students.  If  the  objective 
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were  just  to  hit  an  arbitrary  target  in  the  room,  then  a  two-degree  of  freedom  robot  with 
an  end  effector  would  be  sufficient  as  is  illustrated  in  Figure  3a.  The  simplest  ball¬ 
throwing  robot  would  have  one  link  and  release  from  one  point  with  variable  speed. 
Although  feasible  and  practical,  this  would  not  be  exciting  for  the  students  and  would 
constrain  the  problem  so  much  that  the  mathematical  calculations  would  be  nearly  trivial. 

A  slightly  more  complex  mode  would  be  a  one-link  robot  that  could  release  from 
any  point  along  an  arc  to  achieve  the  desired  range  (Figure  3b).  Such  a  configuration 
would  allow  the  students  freedom  in  choosing  angle  and  release  velocity,  but  in  addition, 
each  release  angle  variation  would  also  change  the  release  point.  Although 
straightforward  to  solve  with  a  system  of  equations,  some  high  school  students  may  not 
have  been  exposed  to  such  methods  and  may  find  it  difficult  to  solve,  without  arbitrarily 
choosing  one  of  the  constraints. 

A  third  method  involves  a  three  degree  of  freedom,  two-link  robot.  A  two-link 
robot  has  the  ability  to  theoretically  achieve  any  velocity  at  a  single  point  within  its 


Four  Mode«  of  throwmg  and  achieving  any  arbitrary  lange. 
(a>  One'Link:  release  from  any  point  on  an  arc  with  any  velocity 
One*tlnk:  release  from  one  point  with  any  velocity 
ic>  Two^Unk:  release  from  one  point  with  any  velocity 

TwcLink:  release  from  any  point  in  a  circle  with  any  velocity 
Inot  shown) 


fa) 


Figure  3  Various  Ball-Throwing  Methods  That  Could  Have  Been  Used 
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workspace  through  a  linear  combination  of  the  two  joint  velocities  fFigure  3c).  This 
allows  for  the  choice  of  the  release  point  by  the  programmer  (choosing  a  point  with  a 
large  range  of  possible  throws),  somewhat  simplifying  the  students’  problem,  but  still 
allowing  them  full  choice  of  velocity  vectors.  Such  freedom  allows  for  discussion  of  the 
advantages  of  different  angles  with  respect  to  flight  time,  air  drag  and  robot  actuator 
saturation. 

Allowing  students  to  choose  release  point  and  release  velocity  introduces  another 
level  of  difficulty.  Such  a  problem  would  have  to  deal  with  actuator  saturation  in 
addition  to  previous  considerations.  Although  relevant  and  applicable,  the  far  too  open- 
ended  calculations  would  be  beyond  the  scope  of  a  high  school  physics  class.  For  these 
reasons  a  three  degree  of  freedom,  two-link  robot  was  chosen,  which,  although  capable  of 
any  release  point,  releases  the  ball  from  the  same  point  every  time  it  throws. 

4.2  Actuator  Selection 

The  decision  to  build  a  ball-throwing  robot  established  some  basic  criterion  from 
which  the  design  process  began.  The  main  objective  was  to  create  a  robot  capable  of 
throwing  balls  to  designated  targets  within  a  classroom  size  area.  This  was  more 
specifically  quantified  as  a  maximum  distance  of  6-8  meters.  This  requires  specific  joint 
velocity  combinations  in  order  to  achieve  such  distances.  Therefore  the  first  step  taken  in 
the  design  process  was  to  calculate  some  example  joint  velocity  combinations  and  the 
correlating  distances  that  the  ball  would  travel  when  released  with  those  initial 
conditions. 
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Some  of  the  example  calculations  are  shown  in  These  calculations  gave  us  a 
baseline  from  which  to  begin  torque  calculations,  which  would  give  us  an  estimate  of  the 
motor  sizes  such  a  robot  would  require  in  order  to  meet  the  stated  objectives. 

The  next  logical  step  in  the  design  was  to  estimate  some  basic  dimensions  and 
masses  of  the  robot  arm  links,  such  that  a  dynamic  model  of  the  robot  could  be 
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mathematically  foraiulated,  from  which  required  torques  could  then  be  calculated. 
Initially  a  Lagrange-Euler  Formulation  of  a  two-link  manipulator  was  used  [4].  The 
model  assumed:  equal  length  forearm  and  upper  arm;  no  friction  and  centers  of  gravity 
located  at  the  midpoint  of  each  link.  The  resulting  equations  of  motion  are  shown  in 
Equation  (1). 

From  this  point  only  angular  position,  velocity  and  acceleration  trajectories  would 
be  needed  to  calculate  the  estimated  motor  torques  necessary  for  a  two-link  manipulator 
to  effect  such  motions. 
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Cl  designates  cosCGj),  S12  designates  sin(0i+02),  etc. 

Two  different  methods  of  trajectory  determination  were  considered  during  these 
initial  stages.  One  method  attempted  to  minimize  individual  motor  torques  by  calculating 
the  smoothest  acceleration  and  deceleration  combinations  for  the  joints  individually.  The 
other  method  used  the  Jacobian  and  inverse  kinematics  to  calculate  the  path  of  the  end 
effector,  which  can  result  in  larger  accelerations  of  the  individual  joints.  The  objective  of 
these  preliminary  calculations  was  to  establish  a  baseline  torque  requirement,  which 
would  designate  the  minimum  motor  sizes  required  to  meet  the  objectives.  Since  the 
objective  was  to  find  the  approximate  minimum  torques  needed,  the  first  trajectory 
calculation  method  was  used. 
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Each  joint  had  an  initial  position,  initial  velocity,  release  position,  release 
velocity,  stop  position,  and  stop  velocity  specified.  This  information  allowed  for  easy 
calculation  of  trajectories  with  smooth  accelerations  of  the  individual  joints  via  cubic 
spline  interpolations.  A  cubic  spline  was  calculated  between  the  initial  and  release  values 
and  a  second  between  the  release  and  stop  values.  The  calculation  of  the  cubic  spline 
provided  the  required  angular  position,  velocity  and  acceleration  values  needed  to 
calculate  motor  torques  Ti  and  T2.  A  Matlab  m-file  containing  these  equations  produced 
the  following  torque  curves  for  joints  one  and  two  as  estimates  of  the  required  torques. 
Notice  in  Figure  4  that  the  example  release  angular  velocities,  4  r/s  and  -21  r/s  correlate 
to  X  and  y  release  velocity  values  of  3  m/s  and  5  m/s  respectively.  This  correlates  to  a 
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range  of  ~8  meters  from ..  Similar  such  calculations  and  data  sets  provided  a  basis  of 
evaluation  for  motors  in  the  marketplace. 

At  this  point  enough  information  was  known  to  begin  shopping  for  motors.  In 
order  to  accomplish  the  objectives  the  robot  would  need  to  be  capable  of:  moving  at  least 
20  r/s  (191  rpm);  exerting  1500  Ozin  of  torque  at  20  r/s;  and  be  affordable.  The  1500 
Ozin  at  20  r/s  occurs  as  a  spike  in  the  torque  trajectory,  therefore  the  motor  would  not 
have  to  be  capable  of  operating  continuously  at  such  high  levels.  After  surveying  the 
possibilities,  surplus  Matsushita  motors  from  Servo  Systems  were  found  to  be  the  best 
combination  of  characteristics  needed  for  this  robot.  Figure  5  shows  the  specifications  of 
the  Matsushita  motors  purchased  from  Servo  Systems.  The  24  V  data  is  that  which  was 
taken  in  the  Servo  Systems  laboratory.  They  tested  at  24  V,  and  therefore  were  not  sure 


Matsushita  Performance  vs  Speed 


Figure  5  Matsushita  Motor  Performance  Data  Published  by  Servo  Systems  Co 
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of  the  maximum  motor  ratings.  This  chart  shows  extrapolated  torque  vs.  speed  curves  for 
12  V  and  36  V  operations  based  on  measurements  of  the  24  V  operations.  Although  at  24 
V  the  motor  does  not  exert  enough  torque,  the  extrapolated  torque  vs.  speed  curve  of  the 
36  V  performance  shows  a  predicted  torque  exceeding  the  levels  needed  for  the  ball¬ 
throwing  robot  arm. 

The  extrapolations  are  based  on  the  idea  that  a  motor  has  a  characteristic  resistor 
value,  back-emf  constant  and  torque  constant.  Equations  (2)  through  (4)  express  the 
electrical  relationship  of  the  voltage  source,  resistor  and  motor,  in  a  steady  state  mode. 

V^=IR  +  k^O}  (2) 

(3) 

T  =  k,I^^a)-^V,  (4) 

In  such  a  mode  of  operation,  the  torque  constant,  back-emf  constant  and  resistor  values 
establish  the  slope  of  the  torque  speed  curve  and  the  supply  voltage  sets  the  intercept 

Servo  Systems  recommended  24V  usage,  but  did  not  have  the  original  motor 
specifications,  therefore  did  not  know  the  current  limitations  of  the  motors.  Their  24V 
tests  never  destroyed  the  motors,  therefore  they  published  that  as  a  safe  operating  level. 
They  did  not  publish  an  operating  level  that  did  destroy  the  motors,  therefore  36  V 
operation  is  unknown. 

Running  the  motor  at  36  V  does  introduce  the  possibility  of  running  too  much 
current  through  the  windings,  melting  the  wires’  insulation  and  destroying  the  motors  in 
the  process.  The  torque  trajectory  simulations  shows  that  a  commanded  torque  at  levels 
requiring  32  V  operation  occurs  for  only  a  fraction  of  a  second.  Such  brief  bursts  of 
power  exceeding  recommended  operating  modes  were  considered  acceptable  because  of 
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the  brief  application  period.  Experience  shows  that  the  higher  voltage  works  fine,  but  it 
will  probably  reduce  the  life  of  the  motor. 

Four  such  Matsushita  motors  were  purchased  from  Servo  Systems  for  use  in  the 
Ball-Throwing  Robot  Arm  Project.  Reasons  for  purchase  included:  the  lower  price  of  the 
surplus  motors  compared  to  other  motors  with  similar  performance  capabilities;  the 
inclusion  of  optical  encoders  with  a  resolution  of  1850  counts/rev  (due  to  the  1:18.5  ratio 
gearhead);  and  the  nearly  ideal  performance  fit. 

Once  the  motors  were  chosen  and  their  potential  power  consumption  levels  were 
estimated  the  choice  of  power  amplifiers  and  power  sources  was  straightforward.  Servo 
Systems  again  provided  the  associated  current  levels  with  each  data  point  of  the  24  V 
operation  regime.  Extrapolation  from  this  data  predicted  that  the  motor  would  require 
approximately  1 1  A  of  current  at  32  V  in  order  to  provide  the  necessary  torque.  Advance 
Motion  Control  builds  a  servo  amplifier,  which  can  supply  a  peak  current  of  12  A  (for  2 
seconds  max)  and  6  A  continuous  current,  using  a  power  source  of  20V-80V.  This  servo 
amplifier  closely  fit  our  needs,  so  we  purchased  three  of  these  and  a  power  source,  which 
can  supply  40V  at  40A  continuously.  The  power  supply  can  supply  all  three  motors  at 
maximum  required  performance.  Such  power  consumption  is  not  expected,  but  the 
equipment  is  capable  of  handling  it. 

4.3  Design  Considerations 

The  following  section  is  included  to  explain  the  reasons  for  which  the  design 
choices  were  made,  which  resulted  in  the  current  Ball-Throwing  Arm  design.  It  outlines 
how  the  design  was  developed  as  well  as  why  various  decisions  were  made.  The 
Engineering  Sketches  of  all  parts  designed  on  ProEngineer  are  included  in  Appendix  A. 
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The  software  ProEngineer  was  used  to  design  and  model  the  robot  in  a  virtual 
environment  before  it  was  actually  built.  The  objective  in  this  effort  was  to  fully  design 
and  assemble  the  robot  in  a  virtual  environment  before  ever  making  a  piece.  Such  virtual 
assembly  would  hopefully  expose  myopic  designs,  integration  conflicts,  and  avoid  time 
intensive  redesigns  later  on.  This  also  allowed  for  the  sizing  and  counting  of  bolts  and 
connectors  beforehand,  such  that  the  appropriate  bolts  and  connectors  could  be  purchased 
ahead  of  time.  Viewing  the  parts  before  construction  also  provided  the  opportunity  to 
determine  whether  or  not  the  parts  were  realistically  machinable.  Although  the  Haas 
CNC  machine  was  available  for  use,  making  pieces  by  hand  proved  much  more 
expeditious  than  making  tooling  plates  and  G-Code  for  all  of  the  parts. 

The  Ball-Throwing  Robotic  Arm  must  be  easy  to  transport  and  move,  therefore 
all  of  the  power  supplies,  power  amplifiers  and  controlling  computer  should  be  compact 
and  centrally  located.  For  this  reason  the  heavy  power  supply  and  power  amplifiers  were 


Figure  6  ProEngineer  generated  image  of  the  Ball-Throwing  Robot’s  Base 
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used  as  ballast  to  hold  the  arm  steady  during  throwing  motions  as  shown  in  Figure  6.  A 
hole  was  drilled  through  the  center  of  the  power  supply  base  plate,  through  which  the 
main  axle  was  mounted.  The  axle  was  mounted  using  two  sets  of  tapered-roller  bearings, 
similar  in  fashion  to  the  mounting  of  a  car  wheel.  This  configuration  constrained  five  of 
six  potential  degrees  of  freedom,  preventing  it  from  shifting  out  of  line  during 
transportation  or  throwing  motions.  The  base  plate  upon  which  all  other  parts  were 
mounted  was  made  of  Vi'  aluminum  versus  the  top  plate,  which  was  14”  aluminum.  The 
top  plate  was  designed  to  flex,  in  order  to  place  pressure  on  the  tapered-roller  bearings, 
preloading  the  bearings,  increasing  structural  stiffness.  Since  the  base  plate  was  twice  as 
thick  as  the  top  plate,  it  has  significantly  less  flex  than  the  top  plate,  therefore 
maintaining  a  flatter  base.  Furthermore  the  steel  base  of  the  power  supply  is  bolted  to  the 
Vi'  aluminum  plate  in  four  places,  providing  further  bending  strength. 

The  motor  used  to  rotate  the  base  can  also  be  seen  in  Figure  6.  This  motor  was 
placed  between  servo  amplifiers  with  the  intent  of  compacting  the  design  as  much  as 
possible.  This  motor  is  connected  to  the  axle  via  a  timing  belt  and  timing  pulleys,  to 
prevent  drift  and  minimize  backlash.  Due  to  the  nature  of  any  belt,  the  design  must 
include  a  mechanism  for  tensioning  the  drive  belts.  The  base  motor  is  encased  in  a 
circular  mount,  which  tightens  around  the  motor  casing  to  fix  it  in  place.  This  particular 
motor  uses  a  gearhead,  which  ends  with  an  offset  drive  shaft.  The  motor  can  be  rotated 
in  either  direction,  which  moves  the  offset  drive  shaft  closer  to  or  further  away  from  the 
axle,  providing  a  method  of  increasing/decreasing  tension  in  the  timing  belt.  Despite  the 
increasing  capability  of  computers,  it  is  always  desirable  to  reduce  the  computational 
load  of  a  processor.  For  this  reason,  it  is  highly  desirable  to  find  a  way  to  control  two 
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motors  dynamically  and  leave  the  third  fixed  vs.  running  three  simultaneously.  To 
accomplish  this  the  movements  of  the  shoulder  and  elbow  motors  must  be  inertially 
isolated  such  that  their  movements  minimally  effect  the  base  motor.  This  idea  was 
incorporated  into  the  design  as  shown  in  the  image  on  the  right  side  of  Figure  7.  The  axis 
of  rotation  (marked  by  a  line)  for  the  base  of  the  robot  runs  close  to  the  rotation  plane  of 
links  1  and  2.  Offsetting  the  cylinder  upon  which  the  upper  links  are  attached  decreases 
the  moment  arm  to  the  base’s  axis  of  rotation,  decreasing  the  effect  of  upper  arm  motion 
on  the  rotation  of  the  base.  The  effects  were  not  necessarily  quantified  and  compared, 
but  the  general  idea  was  implemented.  The  friction  and  effective  inertia  in  the  base 
motor  has  proven  to  be  enough  to  prevent  movement  of  the  base  during  throwing 
motions. 

Figure  7’s  left  image  also  illustrates  the  use  of  the  elbow  motor  as  a 
counterweight,  moving  the  center  of  gravity  for  Link  1  towards  the  shoulder’s  axis  of 


Figure  7  ProEngineer  Rendered  Images  of  Design  Highlights 
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rotation,  decreasing  the  moment  of  inertia.  The  placement  of  the  motor  further  away 
from  the  elbow  also  allows  the  elbow  joint  to  rotate  fully  without  ever  hitting  itself  as 
seen  in  the  left  image  of  Figure  7. 

The  initial  model  used  for  torque  estimates  assumed  no  friction.  This  of  course  is 
ideal  and  not  realistic,  the  mathematical  model  requires  another  term  for  viscous  friction 
and  one  for  coulomb  friction.  The  tedious  part  is  finding  the  coefficients  of  friction  to 
add  to  the  torque  calculations.  To  minimize  friction  as  much  as  possible,  dual  bearings 
were  built  into  the  shoulder  and  elbow  joints.  The  elbow  joint  turned  out  to  have  more 
friction  than  the  shoulder  joint.  This  is  due  to  the  shoulder  motor  bushing  carrying  no 
load  while  the  elbow  motor  bushings  carry  the  load  of  the  elbow  belt  tension.  Besides 
reducing  friction,  the  bearings  act  as  stress  relief  for  the  motor  shaft. 

Another  stress  relief  feature  of  this  robot  was  implemented  after  initial  design, 
construction  and  assembly.  It  was  desirable  to  use  an  acrylic  tube.  During  the  initial 
phases  of  the  robot’s  use  a  crack  developed  on  one  of  the  bolt  attachment  sites  in  the 
plexiglass  tube.  This  necessitated  a  redesign  in  order  to  avoid  tube  failure.  The  tube  had 
been  modeled  as  a  whole  and  found  to  be  strong  enough  to  withstand  the  moments  that  it 
would  experience,  but  no  modeling  of  the  attachment  sites  had  been  performed.  The 
redesign  included  four  14”  steel  rods  placed  parallel  to  the  plexiglass  tube  with  threaded 
ends.  Once  fastened  with  nuts,  each  rod  was  placed  in  tension,  which  compressed  the 
tube,  increasing  its  bending  strength.  After  implementation,  this  redesign  proved 
effective  and  successful  in  preventing  further  cracking  and  the  eventually  failure  of  the 
plexiglass  tube. 
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The  plexiglass  tube  and  its  reinforcements  weren’t  the  only  alternative  materials 
used.  Aluminum  is  inherently  weaker  than  steel  and  develops  fatigue  cracks  faster  than 
steel  under  the  same  loads.  Out  of  all  components,  the  base  axle,  shoulder  and  elbow 
shafts  will  experience  the  largest  loads  during  operation.  Therefore  these  components 
were  constructed  of  steel  instead  of  aluminum. 

Another  materials  issue  that  developed  was  that  of  connection  sites.  Aluminum  is 
much  softer  than  steel  and  therefore  wears  more  quickly  than  comparable  steel.  In  the 
assembly  of  the  robot  some  parts  will  rarely  if  ever  be  disassembled  and  other  could  be 
frequently  assembled  and  disassembled.  Such  frequent  use  of  steel  bolts  in  aluminum 
threads  could  cause  eventual  failure.  Even  more  extreme  is  the  case  of  steel  bolts  in 
plexiglass,  which  is  extremely  soft  relative  to  steel.  For  this  reason,  those  connection 
sites  that  would  experience  frequent  assembly  and  disassembly  needed  some  sort  of 
thread  protection.  Helicoils  were  chosen  as  the  preferred  method  of  protection.  Helicoils 
are  merely  steel  inserts  that  line  a  larger  diameter  threaded  hole  and  provide  a  steel  thread 
base  for  the  bolts  to  connect  to,  reducing  wear  of  the  plexiglass  and  aluminum  threads. 

4.4  Robot  Modeling 

The  precursory  model  used  for  sizing  the  motors  was  derived  via  the  Lagrange- 
Euler  method.  The  Newton-Euler  recursive  method  as  presented  in  John  Hollerbach’s 
course  text  [5]  was  used  to  derive  this  more  specific  model.  This  model  estimates 
inertial,  gravitational  and  frictional  forces.  The  Newton-Euler  Method  is  a  recursive 
algorithm,  which  calculates  the  resultant  torque  on  the  end  joint  (or  force  in  the  case  of  a 
translational  joint)  due  to  forces  and  accelerations  and  then  calculates  the  torque  of  the 
next  joint  and  adds  it  to  the  torque  of  the  end  joint.  This  is  repeated  until  all  joints  have 
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been  accounted  for  and  there  is  an  estimated  torque  for  each  actuator.  Equations  (5) 
through  (16)  show  the  application  of  this  method  to  a  two-link  planar  pair  robot.  The 
base  motor  will  be  stationary  during  dynamic  movement,  allowing  for  use  of  a  two 
degree  of  freedom  dynamic  model. 


/2='”2^  +  /l2 
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(6) 
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When  evaluated.  Equation  (17)  results,  where  cogi  and  cog2  were  replaced  with  their 
numerical  values  of  0.1135m  and  0.08735m  respectively. 
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I  -  inertia  tensor  g  -  magnitude  of  gravity  ^  -  coulomb  friction 

m-mass  1  -  length  ^  -  viscous  friction 

Determination  of  real  inertial  characteristics  can  prove  difficult  and  never  result  in 
anything  but  approximations,  which  can  be  tuned  through  empirical  testing.  The  method 
used  for  finding  better  approximations  of  this  robot’s  inertial  characteristics  was  the 
mechanical  properties  option  calculator  in  ProEngineer.  The  elbow  motor’s  measured 
weight  and  calculated  volume  were  combined  to  find  an  approximate  average  density, 
which  was  then  applied  in  the  arm  assembly.  Once  the  arm  was  virtually  assembled  the 
mechanical  properties  calculator  determined  the  theoretical  c.o.g.’s  and  inertia  tensors  for 
the  virtual  arm  components.  Although  better,  the  estimate  does  not  include  the  elbow 
motor’s  timing  belt  or  the  hand  mechanism’s  spring  or  bowden  cable. 


(17) 
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4.5  Robot  Parameters 


Figure  8  shows  a  Denavit-Hartenberg  rendering  of  the  robot.  Origin  0  of  the  DH 
rendering  is  located  in  the  middle  of  the  rectangular  base  plate  on  the  bottom.  Therefore 
all  measurements  of  distance  should  be  calculated  from  the  center  of  the  base  plate.  The 
following  table  included  in  Figure  8  shows  spatial  and  inertial  parameters  of  the  robot 
used  in  the  kinematic  and  dynamic  calculations. 

4.6  Kinematic  Equations 

The  Ball-Throwing  Robot’s  planar  pair  kinematic  and  inverse  kinematic  equations 
are  shown  in  Equations  (18)through  (23).  A  full  derivation  is  included  in  Appendix  B, 
which  also  includes  a  kinematic  and  inverse  kinematic  derivation  including  the  third 
degree  of  freedom.  The  two  degree  of  freedom  kinematics  structure  is  sufficient  for  the 
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0° 
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0° 

II  3.3 

I23.3 

mi 

1.932  kg 

ni2 

Link  1  c.o.g. 

0.01135  m 

Link  2  c.o.g. 

0.08735  m 

Table  3  Current  Values  for  D-H  and  Inertial  Parameters 


Figure  8  D-H  Parameter  Renresentation  of  Robot  and  Inertial  Parameters  Table 


task  of  throwing,  since  the  base  motor  only  adjusts  the  direction  thrown  and  is  not 
calculated  dynamically,  but  preset  before  the  throw.* 

Position; 
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Velocity: 


Acceleration: 
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'  For  purposes  of  implementation,  the  zero  angle  position  for  the  shoulder  was  redefined  in  all  kinematics 
equations  as  straight  down,  such  that  calibrating  and  resetting  the  encoders  would  be  easier. 
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During  all  path  planning  work  the  robot  was  always  kept  in  the  elbow  down 
configuration  and  the  robot  was  never  commanded  to  pass  through  a  singularity. 


4.7  Hand  design 

The  hand  design  experienced  many  revisions  and  stages  of  development.  The 
driving  requirements  for  the  hand  included:  sufficient  strength  to  hold  the  ball  and  a 
guarantee  of  no  premature  releases;  fast  enough  opening  dynamics  to  minimize  residual 
effects  on  the  ball’s  trajectory;  and  light  weight,  to  minimize  forearm  inertia. 

The  ideal  hand  actuator  would  have  the  ability  to  control  its  position,  the  force 
applied  to  what  it’s  gripping,  have  sufficient  strength  to  hold  the  object  secure  throughout 
the  throw  (for  a  large  rubber  ball,  estimated  at  5.5  Ibf  worst  case)  and  sufficient  speed  to 
release  the  ball  consistently  during  successive  throws.  For  purposes  of  this  project 
sufficient  accuracy  is  being  able  to  throw  into  a  garbage  anywhere  within  the  Throwing 
Arm’s  defined  throwing  range.  Of  these  ideal  characteristics,  the  project  objectives  made 
speed  the  highest  priority  and  strength  second.  The  motorized  hand  actuators  considered 
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would  have  provided  the  position  control,  force  control  and  strength,  but  would  have 
failed  to  provide  the  estimated  necessary  speed  response  using  motors  within  the  assigned 
budget.  This  made  another  method  necessary. 

A  solenoid  from  McMaster  Carr  proved  capable  of  providing  the  necessary  speed 
and  strength.  The  position  and  force  control  are  theoretically  possible,  but  are  beyond  the 
objectives  and  scope  of  this  project  due  to  the  complex  nonlinearities  involved  in  the 
problem.  McMaster  Carr  provided  specifications  data,  which  included  the  solenoid  force 
curve  in  Figure  9. 

The  graph  shows  force  (Ibf)  vs.  displacement  (in)  at  85%  of  its  rated  voltage  (120 
V)-  full  voltage  translates  the  whole  curve  by  adding  approximately  3  Ibf  to  the  whole 
curve.  This  shows  the  greatest  force  at  the  beginning  of  the  pull,  which  implies  that  the 
design  should  take  advantage  of  the  force  spike.  For  this  reason  the  solenoid  was  used  in 
the  design  to  release  the  ball,  which  would  be  held  by  a  spring.  This  design  uses  the 
power  surge,  which  occurs  during  the  initial  opening  of  the  hand  to  expedite  the  opening 
motion,  since  the  opening  segment’s  speed  is  the  most  critical  of  the  opening  movement. 
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Using  a  mass-spring  damper  system  to  model  the  hand’s  dynamics  the  ideal 
spring  constant  was  calculated  as  shown  in  Figure  10.  Ideally  a  spring  could  be  found 
which  would  exert  a  constant  force  instead  of  a  linearly  increasing  spring.  Short  of  a 
constant  force  tape  spring,  the  next  best  option  was  a  long  spring,  such  that  the  one  inch 
of  solenoid  draw  would  minimally  change  the  force  value.  The  equation  of  motion  for 

the  system  shown  in  Figure  10  is: 

mx+bx+kx  =  f  (x)=^  x+(—\x+(—\x  =  ^^  (24) 

'  '  \tn  /  \tn  /  fti 

Jr+2Ca>„i+to^x  =  ^  (25) 

(26) 

In  this  specific  instance  m  =  0. 127feg  +  0.0283^g  =  0.1553fcg  and  k  =  594  ^ ,  which 

leads  to  the  estimate  offt>„  =  =  61.84^  =  9.84/fz .  From  this  the  estimated 

period  is  0.102s  associated  time  required  for  release  of  the  ball  is  0.051s  or  one  twentieth 
of  a  second. 


Figure  10  Spring  Mass  Damper  Model  of  Hand 
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Although  the  solenoid  had  been  chosen  as  the  preferred  method  for  moving  the 
hand,  the  linkage  had  to  comply  with  the  solenoid’s  capabilities.  The  driving  constraint 
of  the  solenoid  came  from  its  one  inch  of  motion.  This  one  inch  of  motion  had  to  be 
converted  into  enough  motion  to  move  the  hand’s  parts  out  of  the  ball’s  path,  such  that  it 
could  escape  with  minimal  interference.  Figure  11  shows  the  linkage  chosen. 

This  linkage  forces  both  “fingers”  of  the  hand  to  moved  synchronously.  The 
movement  was  modeled  mathematically  in  Maple  to  determine  how  the  mechanical 
advantage  varied  through  its  range  of  motion.  Furthermore  it  was  necessary  to  verify  that 
the  single  inch  of  solenoid  motion  would  provide  sufficient  movement  of  the  “finger”  to 
accomplish  the  objectives.  The  optimal  movement  range  was  found  to  be  1.2  to  2.2 
inches  from  the  finger  pivots. 
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The  5.5  Ibf  estimate  of  force  to  hold  the  ball  in  place  is  a  worst  case  estimate  and 
assumes  no  friction  between  the  fingers  and  the  ball.  The  applied  force  curve  in  Figure 
12  can  be  seen  to  exceed  the  worst-case  estimate  for  approximately  0.7  inches  of  the 
solenoid  draw.  This  correlates  to  approximately  30  degrees  of  movement  in  each  finger  - 
full  range  of  motion  provides  approximately  45  degrees  of  rotation  in  the  “fingers”  see 
Appendix  C.  Although  this  should  be  sufficient,  if  the  actual  forces  do  not  approach  the 
5.5  Ibf  estimate,  then  the  spring’s  preload  could  be  reduced,  such  that  the  solenoid  does 
not  have  to  overcome  such  a  large  opposing  force.  Furthermore,  if  needed  the  solenoid 
can  always  be  operated  at  its  full  rated  voltage  to  generate  even  more  force.  In  summary 
these  preliminary  sizing  calculations  showed  that  the  solenoid  design  should  indeed  have 
the  required  speed  and  strength  to  meet  the  stated  objectives. 
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5  Robot  Control 


Construction  and  assembly  of  the  robot  are  only  the  preliminary  steps  of  the  project. 
The  challenging  part  of  the  project  occurs  in  getting  the  robot  to  actually  perform  as 
intended.  This  happens  via  computerized  control  of  the  motors.  In  order  to  declare 
success  in  this  aspect,  the  control  algorithms  implemented  by  the  computer  must  be  able 
to  guide  the  arm  through  the  motions,  matching  the  ideal  movements  close  enough  to  hit 
the  targets  with  the  rubber  ball.  This  requires  significant  computational  capability  to  read 
the  present  data  sets,  analyze  them,  calculate  solutions  and  implement  them  hundreds  of 
times  per  second. 

5.1  Trajectory  Planning 

Two  methods  of  trajectory  planning  were  considered.  The  first  method  uses  a 
cubic  spline  to  interpolate  between  the  start  states,  the  release  states  and  then  another 
interpolation  between  the  release  states  and  the  stop  states.  It  treats  each  joint 
individually  and  does  not  account  for  interim  end  effector  locations.  This  can  lead  to  the 
forearm  rotating  more  than  180  degrees  from  its  initial  position,  which  causes  the  ball  to 
hit  the  upper  arm.  Two  possible  solutions  to  this  problem  include:  1)  moving  the  elbow 
shaft  out  14”  to  circumvent  the  issue  for  1.65”  or  smaller  ball  diameters;  or  2)  use  end 
effector  path  planning  and  inverse  kinematics  to  define  the  joint  trajectories  and  never 
command  the  forearm  more  than  170  degrees  in  either  direction. 

An  advantage  to  the  first  method  is  that  the  computer  programming  is  much 
simpler.  A  general  program  which  can  account  for  all  combinations  of  initial  and  final 
joint  states  is  straightforward  to  write  and  debug.  Such  a  program  is  then  flexible  enough 
to  work  with  any  input  the  students  provide  it.  Furthermore,  it’s  easier  for  a  controller  to 
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track  linear  acceleration  signals,  versus  higher  order  acceleration  curves.  Although  it 
does  hold  these  advantages,  a  major  disadvantage  with  respect  to  consistent  throwing  is 
the  fact  that  the  velocity  vector  is  continually  rotating  throughout  the  whole  throwing 
motion  -  the  ball  is  therefore  always  being  accelerated. 

When  using  end  effector  path  planning,  the  programmer  can  command  the  robot 
to  follow  a  path  of  constant  velocity  for  a  brief  period  before,  during  and  after  ball 
release,  allowing  for  moments  of  zero  applied  force  from  the  arm.  Challenges  arise  when 
writing  a  general  program  to  account  for  all  possible  commanded  throws.  Software  was 
written  to  this  end,  but  a  general  solution  was  never  thoroughly  completed. 

All  tests  were  performed  using  the  cubic  spline  interpolations  for  each  joint 
individually.  At  this  point,  no  testing  of  end  effector  path  planning  has  been  conducted. 
Without  testing  it’s  difficult  to  conclude  with  confidence  whether  or  not  the  accuracy  and 
repeatability  would  have  changed.  Although  a  period  of  zero  acceleration  during  release 
would  have  been  commanded,  the  question  remains  as  to  how  well  the  controller  could 
follow  the  commanded  acceleration  curves. 

5.2  Feedforward  Linearization 

The  Ball-Throwing  Robot’s  control  strategy  uses  a  feed-forward  term  to  cancel  out 
the  system’s  inherent  nonlinearities,  like  gravity  and  asymmetric  inertial  properties.  This 
implies  the  development  of  two  key  elements:  1)  a  more  accurate  mathematical  model  of 
the  manipulator  dynamics  must  be  built  to  include  coulomb  friction,  viscous  friction, 
actual  inertial  properties  and  variable  center  of  gravity  locations  and  2)  a  mathematical 
model  of  the  motors  and  their  response  characteristics  must  be  built,  such  that 
feedforward  torques  can  be  commanded  via  a  voltage  signal  from  the  controlling 
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computer.  The  torque  predictions  could  then  be  used  to  linearize  the  movement  of  the 
robot,  such  that  a  linear  controller  could  then  perform  any  error  corrections  using 
feedback  gains  based  on  linear  control  theories. 

5.3  Actuator  Modeling 

Once  the  computer  interface  was  built  and  assembled,  it  became  relatively  simple 
to  collect  simultaneous  voltage,  current,  position  and  velocity  data  from  the  motors  in 
various  modes  of  operation.  This  data  was  necessary  in  order  to  build  a  mathematical 
model  of  the  motor.  The  dSpace  interface  allowed  the  user  to  command  various  voltages 
while  measuring  the  motor  current  and  angular  position  of  the  motor  shaft.  Once  this 
data  has  been  collected,  the  torque  constant,  back-emf  (ElectroMotive  Force)  constant 
and  motor  winding  resistance  can  be  extracted.  Figure  13  and  Equations  (27)  through 
(28)  summarize  the  tree/cotree  derivation  of  a  motor’s  dynamic  equations  -  the  full 
derivation  is  in  Appendix  D.  The  dynamic  equations  describing  the  system  can  be 
simplified  when  the  motor  runs  at  a  constant  speed  -  all  of  the  derivatives  go  to  zero. 

This  can  be  seen  when  Equation  (29)  is  inserted  into  the  electrical  half  of  Equation  (28) 
and  Equation  (30)  results. 

V,+V„+V,=V(t)  7:+r,+r,.+7,_=0  (27) 


Figure  13  Tree/CoTree  Motor  Model 
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lR  +  k^(0  +  Li=V{t) 


kj.l  +  Ja)j  +B^C0j  +ju  =  0 


(28) 


at  steady  steady  i=0 
IR  +  k^co  =  V 


(29) 

(30) 


Although  the  motor  does  have  inductive  parameters,  the  dynamics  due  to  inductance  fade 
so  quickly  compared  to  the  arm’s  movement  that  they  were  ignored  in  the  modeling  as 
suggested  by  [6].  So,  when  current,  velocity  and  voltage  information  is  available  the 
back-emf  voltage  and  characteristic  resistance  are  readily  obtainable. 

Figure  14  shows  a  plot  of  data  collected  through  the  dSpace  interface.  All  of 
these  data  points  were  collected  during  steady  state  operation.  The  linear  regressions  of 
both  the  forward  and  reverse  data  sets  are  displayed  beside  the  plot.  An  average  of  the 
slopes  was  used  as  the  motor’s  characteristic  resistance  and  an  average  of  the  y  intercepts 
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Figure  14  Data  Used  to  Derive  Motor  Resistance  and  Back  EMF  Constant 
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was  used  as  the  motor’s  characteristic  back-emf  constant.  Once  these  values  are 
determined  it  opens  the  way  to  further  motor  characterization. 

From  the  same  data  sets  even  more  information  can  be  extracted.  Since  all 
measurements  were  conducted  in  metric  units  the  back-emf  constant,  ke  =  kt,  the  torque 
constant,  relating  current  and  torque.  Equation  (31)  describes  the  mechanical  side  of  the 
motor  dynamics. 

0  =  ^7  +  Jd)j  +Ba)j  + 

at  steady  state  d)j=0  (31) 

:.kjI  =  -Ba)j  -fx 

Since  Torque  =  krl,  once  ke  is  known,  then  the  torque  applied  by  the  motor  is  known 
since  the  data  set  includes  current  readings.  Figure  15  shows  the  same  data  expressed  as 
torque  vs.  speed. 


Torque  vs  Speed 
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Figure  15  Data  Used  to  Derive  Friction  Values 
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From  Figure  15  values  of  viscous  and  coulomb  friction  can  be  calculated.  In  both 
the  forward  and  reverse  directions,  there  is  an  offset  or  base  torque,  which  must  always 
be  overpowered  in  order  for  the  motor  to  move.  This  is  coulomb  friction.  Once  the 
motor  begins  moving,  then  the  torque  needed  to  maintain  it  at  certain  speeds  gradually 
increases  as  the  speed  increases.  This  torque  that  increases  with  speed  is  viscous  friction. 
Each  type  of  friction  has  been  estimated  in  an  attempt  to  provide  the  exact  amounts  of 
torque  needed  cancel  out  the  nonlinear  torque  components.  The  viscous  friction  is 
approximately  linear;  therefore  it  is  included  in  the  linear  model  of  the  motor,  and  not  in 
the  nonlinear  correction. 

Figure  16  shows  a  signal  flow  diagram  of  the  Ball-Throwing  Robot’s  Joint  1.  This 
diagram  shows  how  the  feed-forward  torque  is  used  to  linearize  the  system,  allowing  the 
state  space  feedback  gains  to  condition  the  motor  according  to  linear  control  theories. 
Once  the  estimated  torque  and  the  corrective  terms  from  the  state  feedback  lines  combine 
into  the  commanded  torque,  the  inverse  torque  constant  translates  this  value  into  a 
current,  which  is  then  translated  into  a  voltage  by  using  the  empirically  measured 


Non-Linear  Torques 


Figure  16  Signal  Flow  Diagram  of  Joint  1 
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resistance  of  the  motor.  This  signal  causes  the  appropriate  movement  in  the  motor  if 
accurate  nonlinear  estimations  and  appropriate  feedback  gains  are  used. 

At  this  point  the  desired  torques  are  known  and  a  schematic  has  been  proposed,  but 
motors  use  voltage  or  current  inputs,  not  torque  inputs.  Before  such  a  design  can  be 
implemented,  the  little  black  box  called  the  motor  must  be  modeled,  such  that  the  desired 
torque  can  be  converted  into  a  voltage  or  current  to  send  to  the  motor.  Appendix  D 
contains  a  tree/cotree  derivation  of  the  state  space  motor  model  without  inductance.  This 
model  provides  the  basis  for  all  subsequent  controller  design.  The  equations  of  motion 
can  only  help  as  far  as  they  use  correct  parameters.  Values  for  the  torque  constant,  kt, 
and  viscous  friction,  B,  have  already  been  approximated  empirically  via  the  test  data 
introduced  earlier  in  this  section.  That  leaves  the  mass  moment  of  inertia,  J,  yet 
undetermined  for  these  motors. 

The  mass  moment  of  inertia,  J,  can  be  extracted  from  step  response  data.  When 
there  is  overshoot  and  stable  oscillations  decay,  then  the  mass  moment  of  inertia  can  be 
extracted  if  key  values  can  be  measured,  namely  time  to  peak,  tp,  and  percent  overshoot, 
%OS.  These  two  key  data  pieces  allow  for  the  calculation  of  the  system’s  damping  ratio, 
and  natural  frequency,  (On,  which  provide  direct  correlations  to  the  mass  moment  of 
inertia. 

Similar  to  Equation  (26)  for  a  system  with  linear  motion.  Equation  (34)  shows  the 
characteristic  equation  applied  to  rotational  motion.  When  the  empirically  derived  ^  and 
(On  from  the  motors  are  entered  into  the  equations  below,  then  the  only  variable  left 
unknown  is  J.  The  motor  has  no  physical  spring  constant,  K,  just  the  effective  spring  of 
the  unity  feedback  loop.  Therefore  the  (i)n  relation  is  less  valuable,  since  it  would  require 
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a  theoretical  estimation  of  the  effective  K  and  does  not  represent  a  physical  component. 
In  contrast,  the  viscous  friction,  B,  has  been  measured  in  earlier  analysis  and  can  be 
combined  with  the  measured  ^  and  (On  to  estimate  the  mass  moment  of  inertia  for  the 
motor. 


je+Be+Ke= 

0  +  2Ca)„e  +  Q)„=^ 


(32) 

(33) 

(34) 


Data  for  the  shoulder  and  elbow  motors  was  collected  using  a  system  like  the  one 
shown  in  Figure  17.  The  gain,  K,  was  adjusted  until  there  were  a  few  oscillations,  such 
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that  the  overshoot  and  time  to  peak  were  easy  to  measure.  The  adjustment  of  K  is 
inconsequential  for  the  purposes  of  this  data.  The  adjustment  of  K  changes  the 
characteristics  of  the  virtual  spring  in  the  system  that’s  created  by  the  unity  feedback  loop 
shown  in  Figure  17.  It  does  not  change  the  actual  friction  and  mass  moment  of  inertia  of 
the  physical  system.  Furthermore,  when  analyzed  mathematically,  the  adjustment  of  K 
does  not  change  the  denominator  of  the  open  loop  transfer  function.  Therefore  it  does  not 
affect  the  estimate  of  the  mass  moment  of  inertia,  which  only  appears  in  the  denominator 
of  the  transfer  function. 

Eight  step  responses  were  analyzed  for  the  shoulder  motor  and  eight  for  the  elbow 
motor,  from  which  average  values  were  calculated.  The  shoulder  motor  mass  moment  of 
inertia  was  not  measured  since  it  will  not  be  moved  during  the  throwing  motions.  The 
configuration  at  the  time  of  the  measurements  was  not  conducive  to  the  measurement  of 
base  motor  mass  moment  of  inertia.  Furthermore  the  base  motor’s  friction  is  sufficient  to 
hold  it  steady  during  the  throwing  motions  of  the  arm;  therefore  a  precise  dynamic  model 
of  the  base  motor  configuration  is  not  necessary.  The  base  motor’s  mass  moment  of 
inertia  is  greater  than  the  other  two  motor’s  mass  moment  of  inertia,  therefore  an  estimate 
of  its  value  was  made  to  use  when  needed,  but  the  estimate  is  not  based  on  data  collected 
from  the  base  motor.  With  defined  motor  parameters,  all  the  information  needed  to 
derive  a  state  space  model  is  available  for  controller  design. 

5.4  Tracking  Error  Compensation 

The  feedforward  linearization  theoretically  cancels  out  all  of  the  manipulator 
nonlinearities,  allowing  for  a  linear  controllerto  be  implemented.  Theoretically,  the 
feedforward  term  can  cancel  out  all  nonlinearities.  Then  from  the  linear  controller’s 
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perspective,  it  appears  to  move  only  the  motor,  with  no  additional  load  attached  to  it. 
The  moving  position  reference  and  velocity  reference  provide  the  input  for  the  linear 
controller  to  follow.  Although  the  feedforward  term  is  calculated  as  accurately  as 
possible,  it  can  never  be  perfect  in  a  real  world,  therefore  errors  will  arise,  which  require 
a  controller  strong  enough  to  correct  for  inherent  modeling  errors  and  disturbances. 

State  space  methods  were  used  to  model  and  build  the  linear  controller.  This 
controller  ideally  needs  to  have  the  ability  to  correct  for  errors  quickly  and  accurately. 
The  resulting  equations  of  motion  derived  in  Appendix  D  are: 


For  purposes  of  discussion,  let  A,  B  and  C  relate  to  the  matrices  of  Equation  (35)  as 
shown  in  Equation  (36). 

X  =  Ax  +  Bu 

y  =  Cx  (36) 

where  x  is  a  vector  of  states,  u  is  the  input  and  y  is  a  vector  of  outputs 

Using  full-state  feedback,  poles  can  theoretically  be  placed  anywhere.  This 
guarantees  stability  of  the  linear  portion  of  the  controller.  The  poles  are  placed  in 
commanded  positions  by  calculating  the  feedback  gains  for  the  states.  Figure  16  shows  a 
diagram  of  a  motor  with  position  and  velocity  feedback  -  full-state  feedback  in  the  case 
that  inductance  and  amplifier  filtering  are  ignored.  When  implemented  the  new  system 


is: 


x={A-B\k^  + 

y = Cc 


(37) 
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The  only  thing  left  is  the  choice  of  pole  locations.  The  robot  arm  will  have  to 
follow  a  trajectory  which  will  start  with  zero  velocity  and  will  accelerate  smoothly  to  a 
release  velocity  and  then  decelerate  again  to  zero  velocity  while  returning  to  the  start 
position.  The  micro  controller  will  run  at  750  Hz,  updating  the  reference  values  each 
sample.  Ideally  the  robot  joints  will  execute  a  short  period  of  constant  angular  velocities, 
such  that  the  controller  can  converge  on  the  ideal  trajectory  and  hold  it  through  the  throw 
instead  of  forcing  the  robot  to  release  the  ball  on  a  velocity  trajectory  spike.  This  brief 
release  moment  only  lasts  0.05  s.  The  controller  needs  to  correct  for  position  and 
velocity  reference  changes  fast  enough  to  converge  before  0.025  s,  when  the  hand 
releases  the  ball. 

In  order  to  converge  on  this  velocity  and  follow  it,  the  compensated  system  should 
have  a  natural  frequency  twice  as  fast  as  this.  This  correlates  to  poles  with  a  natural 


Root  Locus 
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frequency  of  250  r/s.  Figure  18  shows  a  root  locus  for  the  second  order  motor  system. 
Poles  with  ^  of.766  and  (On  of  250  r/s  as  shown  have  associated  feedback  gains  of  -43.1 
and  -0.27  Ifor  position  and  velocity  respectively. 

This  root  locus  may  be  deceptive  since  it  is  based  upon  only  two  poles.  This  implies 
that  the  motor  can  never  go  unstable.  A  third  pole  actually  exists  due  to  inductance, 
maybe  a  fourth  due  to  noise  rejection  filtering  in  the  amplifiers.  Therefore,  the  motor 
may  become  unstable  with  high  gains.  Most  likely  the  amplifiers  would  saturate  and  the 
motor  would  just  enter  a  stable  limit  cycle. 

Through  the  combination  of  a  feedforward  term  to  cancel  manipulator 
nonlinearities  and  a  fast  full-state  controller  to  correct  for  errors  while  tracking  position 
and  velocity  trajectories  a  controller  was  designed  to  accomplish  the  objectives  of  the 
ball-throwing  arm  project. 
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6  Robot  Implementation 


6.1  Safety  Issues 

The  robot,  when  fully  assembled,  controlled  and  well  behaved,  should  pose  no 
threat  to  the  students  or  operators.  Reality  always  exposes  new  failure  modes  and  design 
weaknesses.  For  this  reason  all  potentially  dangerous  aspects  of  the  robot  must  be 
considered  and  addressed.  Especially  since  this  robot  will  be  taken  to  high  schools  to 
perform  demonstrations  for  students.  The  chance  of  failure  resulting  in  injury  must  be 
reduced  to  virtually  zero. 

6.1.1  Mechanical 

The  elbow  and  base  motors  are  connected  via  timing  belts,  therefore  slipping  is 
possible  if  there  is  binding  for  any  reason.  The  shoulder  motor  has  a  direct  connection 
and  will  not  slip  without  breaking  part  of  the  gear  train  or  steel  shaft.  These  motors  were 
lab  tested  at  175  watts  continuously  by  servo  systems.  The  power  source  and  amplifiers 
could  source  as  much  as  480  watts  per  motor,  sufficient  mechanical  power  to  injure  and 
maim  a  person,  especially  since  the  shoulder  motor  will  not  slip,  it  will  either  stall,  break 
the  robot  structure  or  break  the  obstruction. 

Certain  precautions  were  built  into  the  robot  in  order  to  avoid  accident  and  injury. 
The  first  and  foremost  safety  feature  is  one  of  distance.  All  operation  of  the  robot  will  be 
performed  outside  its  workspace.  For  those  instances  when  the  workspace  may  be 
approached  or  encroached  by  a  person,  another  safety  feature  has  been  integrated. 

The  kill  switch  is  simple  and  effective.  It  connects  the  capacitor  output  to  the 
servo  amplifiers’  inputs.  The  kill  switch  can  instantaneously  interrupt  power  to  the 
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motors  of  the  robot  or  prevent  it  from  beginning  a  movement.  Although  the  kill  switch 
disables  the  motors,  it  does  not  eliminate  the  danger  of  electrical  shock,  which  is 
discussed  in  the  next  section. 

Once  the  motors  have  been  disabled  the  only  motion  not  aborted  by  the  kill  switch 
is  the  solenoid,  which  operates  independent  of  the  power  supply  capacitor.  This  is 
acceptable  considering  the  potential  of  an  injury  resulting  from  the  motion  of  the  hand 
assembly.  There  is  only  one  potential  pinch  point  in  the  hand  assembly  when  the  kill 
switch  is  off.  It  is  shown  within  the  circled  area  in  Figure  19.  When  the  solenoid  plunger 
reaches  the  end  of  its  one-inch  pull  it  will  exert  no  more  than  nine  pounds  of  force 
between  the  pull  rod  and  the  attachment  fixture.  The  solenoid  has  proven  to  startle 
people  with  its  noise  much  more  than  with  its  actual  movement  or  effected  movement. 


Figure  19  Pinch  Point  in  Robot  Hand 
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6.1.2  Electrical 


The  power  source  is  connected  directly  to  120  VAC.  The  transformer  connections 
are  exposed  within  the  robot  base  area.  Any  person  working  within  the  base  area  of  the 
robot  must  know  of  this  potential  danger  and  take  proper  precautions.  The  power  supply 
uses  a  full-bridge  rectifier  and  a  capacitor  to  reduce  ripple.  The  capacitor  is  rated  at 
13mF  -  large  enough  to  seriously  injure  and  capable  of  killing  a  person  in  certain 
situations.  Equation  (38)  calculates  the  amount  of  energy  stored  in  this  capacitor  when 
charged. 

t/=lCy^=^(.024)(40)^=19.2/  (38) 

Currents  of  5mA  or  less  rarely  cause  damage,  but  100mA  for  1.3  seconds  through  the 
heart  is  sufficient  current  to  kill  a  person.  Such  a  current  can  be  induced  by  40V  under 
the  right  conditions.  Furthermore,  this  is  a  DC  voltage,  which  penetrates  skin  and 
muscles  more  than  60  Hz  current  [7].  For  this  reason,  the  robot  electrical  system  must  be 
respected  as  such  and  should  have  a  shield  in  place  preventing  students  from  touching 
dangerous  components  within  the  robot  base. 

6.2  Sensing  Systems  and  Control  Hardware 

6.2.1  dSpace 

The  dSpace  system  is  a  DS1103  board  and  its  associated  software.  The  hardware 
includes  a  PowerPC  604e  with  a  400  MHz  processor,  2  MByte  local  SRAM,  32-  or  128- 
MByte  global  DRAM,  16  ADC  channels,  8  DAC  channels,  32  digital  I/O  channels,  and 
many  more  features,  which  this  project  did  not  use.  The  dSpace  board  can  take  Matlab’s 
Real  Time  Workshop  Simulink  models  and  implement  them  real  time.  It  also  allows  for 
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the  building  of  graphical  user  interfaces  (GUI’s)  rapidly  and  easily.  This  made  for  a 
powerful  interface  of  the  computer  and  the  robot  hardware. 

The  Ball-Throwing  Robot  uses  the  DS1103  to  collect  precise  position 
information,  process  the  control  algorithms  and  then  output  the  control  voltages  to  each 
individual  motor.  Each  motor  has  an  optical  encoder  mounted  on  it,  which  transmits 
quadrature  signals  to  the  processor  through  15-pin  subD  connectors  for  decoding  by  the 
DSl  103  processor.  The  robot  currently  uses  encoder  channels  4-6.  The  control 
algorithm  is  visually  built  and  integrated  in  Matlab’s  simulink  with  Real  Time  Workshop 
blocks,  then  compiled  and  loaded  onto  the  DSl  103.  Once  loaded,  it  collects  and 
manipulates  data,  outputting  the  resulting  control  signals  via  DAC  channels  5-8.  A 
program  for  characterizing  the  motors  was  developed  which  included  the  use  of  a  ADC 
channel  to  measure  the  current  monitor  on  the  servo  amplifiers. 

6.2.2  Position  Sensing 

The  sensing  system  for  this  robot  is  currently  composed  of  encoders.  The  encoder 
sends  out  two  streams  of  pulses.  The  pulse  streams  are  always  90  degrees  out  of  phase  of 
one  another  as  shown  in  Figure  20.  The  relative  phase  lead  and  lag  of  the  pulses  implies 
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the  direction  of  movement.  Each  motor  encoder  has  100  pulses  per  revolution.  There  are 
two  states  per  pulse,  on  and  off.  One  pulse  stream  is  sufficient  to  detect  how  far  the 
motor  has  rotated,  but  cannot  detect  direction.  Two  pulse  streams  contain  four  possible 
states  -  00, 01, 10, 1 1  -  as  illustrated  in  Figure  20.  The  algorithm  receiving  the  data  can 
compare  the  current  state  with  the  previous  state  to  determine  direction  and  counters  can 
keep  track  of  absolute  position.  The  four  state  per  pulse  configuration  allows  for  four 
discrete  positions  per  pulse,  which  translates  into  400  discrete  positions  per  revolution 
and  18.5  *  400  =>  7400  discrete  positions  per  output  shaft  revolution.  This  accuracy  is 
indeed  greater  than  what  is  required  for  this  robot’s  objectives. 

Although  all  of  the  control  is  based  upon  the  encoders,  the  design  incorporated 
potentiometer  verification  of  the  encoder  position,  which  would  provide  a  method  of 
auto-calibration  too.  Figure  21  shows  a  potentiometer  attachment  site.  The  current 


Figure  21  Potentiometer  Option  for  Redundant  Position  Sensing 


48 


configuration  of  the  robot  does  not  include  implementation  of  the  potentiometers,  just  a 
design,  which  can  incorporate  potentiometer  verification  and  calibration  of  the 
potentiometers.  Implementation  would  require  another  three  ADC  channels  and  further 
computational  support  to  account  for  the  three  potentiometers,  but  if  desired  they  can  be 
implemented. 

6.2.3  Servo  Amplifiers 

Another  integral  piece  of  the  control  hardware  is  the  servo  amplifier.  As  earlier 
stated,  this  robot  uses  three  Servo  Systems  Pulse  Width  Modulated  (PWM)  12A8  servo 
amplifiers.  These  have  the  ability  to  operate  in  a  current  following  or  voltage  following 
mode,  sourcing  6A  continuously  and  12A  peak  at  20V-80V,  with  a  switching  frequency 
of  36kHz  and  operational  bandwidth  of  2.5  kHz  depending  on  the  applied  load.  It  has 
adjustable:  loop  gain;  current  limit;  reference  gain;  and  offset/test.  These  are  just  a  few 
of  the  specifications  most  applicable  to  this  application.  The  amplifiers  were  adjusted  to 
have  zero  offset  and  a  reference  gain  of  four. 

The  reference  gain  of  four  arises  from  dSpace’s  voltage  output  limitations.  The 
dSpace  DAC  converters  are  capable  of  up  to  10  volts  out.  The  power  supply  provides  up 
to  40  volts,  thus  a  gain  of  four  was  used  to  allow  for  the  full  range  of  voltage  application. 
Another  non-intuitive  gain  is  a  dSpace  gain.  The  voltage  commanded  in  the  GUI  is 
multiplied  by  10  at  the  DAC  voltage  out. 

6.3  Micro  Controller 

The  dSpace  DSl  103,  although  well  adapted  for  this  project,  easy  to  use  for 
implementing  new  programs  and  much  faster  than  needed  for  this  project,  is  not 
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particularly  portable.  It  operates  out  of  a  desktop  PC  and  has  many  large  cables 
associated  with  it.  For  this  reason,  from  the  very  beginning  the  project  included  the  idea 
of  a  single  board  computer  controller.  Such  a  computer  would  provide  a  portable 
controller  and  user  interface,  through  which  the  students  could  command  the  robot 
through  various  movements. 

After  two  and  a  half  months  of  shopping  and  research  the  Z-World  PK2600  was 
chosen.  The  PK2600  is  a  controller  unit,  which  includes  two  19  MHz  Z180  Zilog 
processors.  One  processor  controls  a  Vi  VGA  touch  screen  monochrome  interface  and 
the  second  processor  controls  the  I/O  ports.  The  display  processor  runs  all  of  the  user 
interface  programs,  introducing  the  project,  displaying  menus  and  taking  the  data  needed 
to  command  the  robot.  The  display  then  ports  the  information  to  the  controller  processor 
via  an  internal  RS-232  serial  link.  The  information  can  be  used  to  precalculate  the  torque 
trajectories  for  the  desired  robot  arm  motion.  When  ready,  an  execute  button  on  the 
display  can  be  depressed,  sending  the  command  signal  to  the  controller  processor  to  start 
the  throwing  motion.  The  user  interface  and  internal  communication  routines  are  still 
under  construction  by  Roy  Merrell  and  Danny  Blanchard. 

The  controller  has  32  lines  of  digital  I/O.  These  lines  can  be  configured  in  any  of 
the  following  combinations:  8  in  /  24  out;  16  in  /  16  out;  or  24  in  /  8  out.  Either  16  or  24 
lines  of  digital  inputs  are  used  to  read  in  two  motor  encoder  signals  simultaneously.  Due 
to  the  relatively  slow  speed  of  this  processor,  decoding  the  quadrature  signals  in  the 
software  algorithm  could  prove  burdensome  and  significantly  decrease  the  sampling  rate 
of  the  controller.  Agilent  Technologies  donated  external  quadrature  decoders  to  solve 
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this  problem^.  Although  dSpace  distinguishes  quarter  pulse  positions,  the  Agilent 
quadrature  decoders  only  resolve  whole  pulses.  These  quadrature  decoders  count  the 
quadrature  pulses,  measure  the  phase  relationship  to  determine  the  direction  and 
magnitude  of  the  movement  and  output  the  position  via  digital  lines.  These  digital 
signals  are  read  by  the  controller  to  determine  position  and  velocity  for  use  in  the  control 
algorithm.  The  controller  calculates  the  outputs  and  has  7  PWM  analog  channels  to  use 
to  send  the  signals  to  the  amplifiers. 

The  quadrature  chips  have  various  modes  of  operation:  8-bit;  12-bit;  and  16-bit 
counters.  Each  obviously  has  its  advantages.  The  16-bit  counter  is  normally  used  for 
absolute  position  monitoring  and  the  8-bit  has  options  adapted  specifically  to  incremental 
operation.  The  robotic  arm  was  originally  designed  to  channel  two  streams  of  8-bit 
position  information,  one  from  each  quadrature  chip  to  the  controller  through  a  single  16 
line  digital  input  port.  This  method  was  encountering  drift  errors  during  operation. 

The  incremental  operation  mode  requires  a  reset  signal  from  the  controller 
immediately  after  a  measurement  is  taken  to  reset  the  counter,  such  that  overflow 
between  samples  is  avoided.  Although  the  source  and  nature  of  this  drift  is  yet 
unexplained,  a  possible  explanation  results  from  the  speed  of  the  controller.  One  line  of 
code  measures  the  current  position  and  the  counter  is  not  reset  until  the  next  line  of  code 
executes.  Any  movement  between  the  measurement  of  position  and  the  reset  command 
would  be  lost  entirely. 

One  possible  remedy  would  involve  a  different  digital  I/O  port  configuration. 
Currently  there  are  16  digital  lines  in  and  16  digital  lines  out.  If  the  configuration  were 
changed  to  24  lines  in  and  8  lines  out,  then  each  motor  could  use  the  quadrature  decoder 
^  Data  Sheets  included  in  Appendix  I 
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counter  as  an  absolute  position  reference  in  stead  of  as  an  incremental  position  reference. 
This  would  introduce  another  level  of  complexity. 

The  quadrature  decoders  each  have  only  8  lines  of  digital  output,  therefore  the  12 
and  16  bit  counters  must  be  serially  output  8  bits  at  a  time.  This  would  require  more  code 
to  read  the  position.  The  controller  would  then  use  one  line  of  code  to  read  the  Motor  1 
position  and  the  next  line  to  read  Motor  2.  This  would  require  a  different  circuit  design 
which  would  use  a  controller  commanded  signal  to  regulate  which  quadrature  chip’s 
signal  was  passing  to  the  input  port  at  which  time.  This  would  allow  the  controller  to 
latch  the  data  for  read  processes  and  not  lose  data  due  to  movement  during  the  read 
period.  The  quadrature  decoders  continue  real-time  position  monitoring  in  the 
background  even  when  data  has  been  latched  to  the  output  ports,  therefore  drift  would  not 
arise  from  slow  controller  coordination. 

6.4  Control  System  Prototyping 

The  controller  described  in  Section  5  was  conceptually  built  and  simulated  early  in 
the  robot’s  development.  When  implemented  and  tested  the  results  were  not  fully 
satisfactory.  The  variance  in  the  robot’s  throwing  performance  was  too  sporadic.  The 
robot’s  hit  spread  at  a  distance  of  12’  was  larger  than  the  lab  garbage  can  -  about  14”, 
which  is  unsatisfactory.  The  robot  should  be  able  to  consistently  throw  into  an  area  the 
size  of  a  garbage  can  and  ideally  much  smaller.  This  way,  the  robot  could  compete 
against  a  student  for  accuracy  and  consistency  and  win.  For  this  reason,  the  controller 
had  to  be  modified. 

Various  things  like  empirical  gain  adjustment,  different  feedback  arrangements  and 
model-based  control  were  tried.  The  initial  position  and  velocity  gains  were  adjusted  and 
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empirically  tuned.  The  result  was  an  aggressive  controller  with  increased  consistency, 
but  still  not  good  enough. 

The  next  variation  tried  was  acceleration  error  feedback.  When  attempting  to  speed 
up  the  tracking  response  of  the  original  controller,  velocity  oscillations  developed  as  the 
controller  tried  to  converge  on  the  velocity  trajectory.  Velocity  feedback  is  commonly 
used  to  damp  out  oscillations  in  a  position  control  system.  Similarly  it  made  sense  that 
acceleration  feedback  could  feasibly  damp  out  velocity  oscillations.  So  it  was  added. 

The  change  was  dramatic.  The  velocity  oscillations  disappeared  and  the  system  tracked 
both  position  and  velocity  profiles  better  than  ever  before.  The  tough  question  though 
was  what  gain  to  assign  to  the  acceleration  feedback.  The  gain  implemented  was  tuned 
through  multiple  trials.  Another  side  effect  of  the  acceleration  feedback  used  proved  to 
be  a  safety  improvement  for  the  system. 

Previous  controllers  experienced  quick  jerks  when  large  step  disturbances  were 
encountered.  For  example  if  the  arm  was  jarred  to  a  nonzero  position  while  the  power 
was  off  and  the  power  was  subsequently  applied,  then  the  links  would  quickly  jerk  back 
to  position,  sometimes  experiencing  limit  cycles  around  their  desired  position.  The 
flailing  links  could  potentially  injure  a  person  if  in  the  way. 

Part  of  the  reason  for  this  behavior  is  because  the  system  is  not  feedback  linearized, 
but  feedforward  linearized  and  when  the  robot’s  feedforward  trajectories  are  not 
streaming  into  the  controller,  then  the  linear  controller  is  attempting  to  control  a  very 
large  nonlinear  inertia  for  which  it’s  not  designed.  When  the  acceleration  gain  was 
added,  it  killed  the  limit  cycle  tendencies  because  the  post  throw  acceleration  and 
velocity  references  are  zero  they  tame  the  position  feedback  signal,  such  that  the  links 
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creep  back  to  the  desired  position  at  very  slow  rates,  taking  sometimes  five  second  to 
move  back  to  the  desired  position.  Such  a  slow  speed  does  not  endanger  anyone,  but 
when  used  to  track  trajectories  there  is  no  velocity  oscillation  and  the  results  were  the 
most  consistent  of  any  controller  used  thus  far.  A  challenge  resulting  from  such 
implementation  is  that  no  theory  found  explains  how  to  choose  an  acceleration  feedback 
gain.  The  closest  method  found  is  model-based  control. 

Model-based  control  attempts  to  make  the  motor  appear  like  a  block  with  unit 
inertia  to  the  controller.  When  configured  for  tracking  a  trajectory,  the  acceleration  term 
is  added  directly  into  the  control  signal  as  a  feedforward  term  as  shown  in  Figure  22. 
This  was  attempted  in  parallel  with  the  feedforward  linearization  developed  earlier. 
Equations  (39)-(44)  derive  the  idea  behind  this  method  as  presented  by  [6].  They  show 
that  kp  and  ky  can  be  chosen  to  command  any  error  response  desired,  assuming  that  the 
system  is  correctly  modeled. 


mx-\-bx+kx  =  f 

(39) 

f  =  af'+e 

(40) 

Figure  22  Model-Based  Controller  Signal  Flow  Diagram 
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Define: 


a  =  m 
P  =  bx  +  kx 

Insert  Equation  (41)  into  (40)  and  then  (40)  into  (39)  to  get: 

x  =  f' 


(41) 


(42) 


From  Figure  22: 

f’=xj+k^(xj-x)+k^{xj-x)  =  xj+k^e  +  kpe  (43) 

Combine  (42)  and  (43)  to  get: 

Xj-x+k^e  +  kpe  =  ej+k^e  +  kpe  =  0  (44) 

This  shows  that  the  choice  of  position  and  velocity  feedback  gains  can  create  an 
error  signal  that  always  decays  to  zero.  A  critically  damped  response  occurs  when 

k^  =  2.yJ^ .  These  two  controllers  were  implemented  along  with  the  original  controller. 

These  two  subsequent  controllers  proved  much  more  effective  than  that  in  the  original 
design. 

7  Testing  and  Performance 


7 . 1  Operating  Procedures 

Appendix  E  contains  a  set  of  dSpace  operating  procedures  as  well  as  the  code  used 
throughout  the  controller  with  explanatory  comments.  These  instructions  will  lead  a  user 
through  all  the  startup  steps  involved  in  getting  the  robot  ready  to  throw. 

Once  all  initialization  and  setup  is  complete,  then  the  dSpace  graphical  user 
interface  is  the  main  portal.  All  parameters  except  link  centers  of  gravity  can  be  adjusted 
through  the  GUI.  This  allows  for  fine-tuning  on  the  fly.  Once  all  parameters  have  been 
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chosen,  the  power  button  may  be  depressed,  connecting  the  capacitor  to  the  power 
amplifiers.  At  this  point,  the  Move  button  should  be  depressed  once  to  adjust  the  base 
motor  angle  then  the  Start  button  should  be  depressed  to  execute  the  throwing  sequence. 
Once  the  arm  has  thrown  and  moved  back  to  its  initial  position,  then  the  power  button 
should  be  released,  making  the  arm  perfectly  safe  to  approach. 

7.2  Experimental  Setup 

All  throwing  experiments  were  performed  in  MEB  2178.  Figure  23  shows  how  the 
robot  sits  on  a  cabinet  in  the  office,  from  which  it  throws.  A  pillow  of  packing  bubbles 
caught  the  ball  and  the  distance  thrown  was  recorded. 

7.3  Results 

Many  test  throws  were  performed  with  the  intent  of  determining  the  Throwing 
Arm’s  accuracy  and  repeatability  -  299  of  these  throw  distances  were  recorded. 

Appendix  F  contains  tables  summarizing  all  test  data.  Tools  used  to  collect  informative 
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data  included  telemetry  via  the  dSpace  interface,  a  digital  video  camera  and  a  standard 
tape  measure.  For  each  combination  of  release  velocities,  multiple  throws  were  observed 
and  recorded.  Those  results  were  averaged  to  find  average  throwing  distances  for  each 
setting.  The  error  between  the  predicted  distance  and  the  average  throw  distance  and  the 
standard  deviation  of  the  actual  throw  distances  was  calculated.  The  data  presented 
compares  the  two  most  successful  controller  designs  implemented  thus  far,  the  model- 
based  controller  and  the  acceleration  feedback  controller. 

The  model-based  controller’s  accuracy  grew  continually  worse,  the  farther  it  tried 
to  throw.  Its  decrease  in  accuracy  declined  at  a  faster  rate  than  the  acceleration  feedback 
controller.  Figure  24  shows  the  predicted  distance  on  the  x-axis.  The  data  points 
represent  the  error  between  the  average  throw  distance  and  the  predicted  distance  and  the 
standard  deviation  of  the  throw  distances.  For  the  model-based  controller,  both  the 
consistency  and  the  accuracy  of  the  robot  at  each  setting  grew  continually  worse  as  the 


Model-Based  Controller  Results  vs  Distance 


Figure  24  Test  Data  from  Model-Based  Controller  Throws 
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Average  Error  &  Standard  Deviation  (in) 


distance  increased.  The  consistency  declines  linearly,  while  accuracy’s  decline  appears 
parabolic. 

The  acceleration  feedback  controller  test  data  is  different  for  the  same  commanded 
trajectory  profiles.  Figure  25  shows  the  results  in  the  same  format  as  the  model-based 
controller  data  in  Figure  24.  The  acceleration  feedback  controller’s  standard  deviation 
also  changes  in  an  approximately  linear  fashion,  getting  worse  the  farther  the  robot 
throws,  but  the  slope  of  its  trend  line  is  smaller  than  the  model-based  controller’s. 
Furthermore  the  consistency  of  the  acceleration  feedback  controller  declines  at  a  slower 
rate  than  the  model-based  controller. 


Acceleration  Feedback  Controller  Results  vs  Range 


I  e  Average  Error  (in) 

I  ■  Standard  Deviation  (in) 


Figure  25  Test  Data  from  Acceleration  Feedback  Controller  Throws 
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Although  the  model -based  controller’s  error  seemed  to  grow  parabolicly,  the 
acceleration  feedback  controller  does  not  seem  to  have  an  error  that  is  an  explicit  function 
of  distance.  Instead  further  analysis  of  the  data  suggests  that  the  error  is  a  function  of  the 
commanded  release  angle  and  distance.  For  near  zero  release  angles,  the  error  was  a 
function  of  distance  similar  to  the  model-based  data  in  that  the  accuracy’s  decline  could 
be  approximated  parabolicly.  Figure  26  shows  the  data  collected  during  near  zero  release 
angles  throws.  The  10  to  45  degree  release  angle  throws  show  a  very  different  trend. 
There  is  no  particular  relation  between  release  angle  and  error,  but  as  a  group  the  error  is 
quite  small  compared  to  the  model-based  controller.  For  the  same  commanded 
trajectories,  the  model-based  controller  had  only  three  throws  with  less  than  10  inches  of 
error,  the  acceleration  feedback  controller  in  contrast  had  only  three  throws  with  more 
than  10  inches  of  error.  Common  to  all  is  the  steady  increase  of  the  standard  deviation. 
Out  of  all  data,  the  throws  released  at  angles  of  10-45  degrees  have  the  smallest  standard 


Near  Zero  Degree  Departure  Angle  Throws 


■Average  Error  (in) 

A  Standard  Deviation  (in) 

♦  Departure  Angle  (degrees) 


Figure  26  Acceleration  Feedback  Throws  with  Near  Zero  Departure  Angles 
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deviation  slope  of  any. 

The  next  question  asks  for  an  explanation  of  why  the  model-based  controller  does 
not  have  the  accuracy  or  the  consistency  of  the  acceleration  feedback  controller.  The 
model-based  controller  relies  upon  accurate  modeling  of  the  motors  and  their  loads. 

Figure  15  on  page  36  shows  some  of  the  data  from  which  the  motor  model 
parameters  were  derived.  Figure  15’ s  data  does  not  fit  any  line  very  closely.  When 
averaged  it  reflects  a  general  slope,  but  is  far  from  the  ideal  that  theory  predicts.  All  data 
collected  from  these  motors  was  just  as  noisy.  The  parameters  derived  from  this  data 
may  be  flawed.  Furthermore,  all  of  these  parameters  are  characteristic  parameters  used  to 
linearize  nature,  which  is  essentially  non-linear.  They  are  all  approximations  that  help  us 
try  to  predict  nature.  Another  tool  provides  more  insight  into  this  question. 

The  dSpace  data  capture  illuminates  what’s  happening  inside  each  controller. 
Appendix  G  overlays  the  responses  of  both  controllers  to  the  same  input  trajectories.  The 


10-45  Degree  Departure  Angie  Throws 


■Average  Error  (in) 

A  Standard  Deviation  (in) 

A  Departure  Angle  (degrees) 


y  = -0.024ax  - 1.2639 
R*  =  0.9102 


Figure  27  Acceleration  Feedback  Throws  with  10-45  Degree  Departure  Angles 
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model-based  controller  velocity  signal  has  oscillations  and  drops  off  quickly  at  the  points 
of  sudden  acceleration  changes.  In  contrast  the  acceleration  feedback  has  virtually  no 
velocity  oscillations  and  holds  the  zero  angular  acceleration  regions  better  than  the 
model-based  controller.  The  acceleration  feedback  controller  holds  its  velocities 
relatively  constant  through  the  ball  release  segment  and  matches  the  desired  velocity 
closer  than  the  model-based  controller.  The  model-based  controller  has  oscillatory  peaks 
that  can  vary  in  magnitude  and  timing.  This  could  explain  the  model-based  controller’s 
generally  lower  accuracy  and  its  lower  consistency. 

One  characteristic  common  to  both  controllers  is  a  slight  lag  in  the  velocity 
tracking,  most  noticeable  in  the  shoulder  velocity  profiles.  Both  break  at  the  instant  the 
acceleration  goes  to  zero  and  both  have  approximately  the  same  lag.  When  implementing 
the  velocity  feedback,  the  incremental  encoder’s  position  signal  was  filtered  and 
differentiated.  The  filter  is  second  order  with  a  break  frequency  of  70  r/s,  so  the  velocity 
signal  is  delayed  before  it  enters  the  control,  which  has  its  own  natural  response  delay. 
This  may  be  an  evidence  of  those  delays  in  the  system. 

An  attempt  was  made  to  observe  the  interaction  that  occurs  during  the  release  of  the 
ball,  to  see  how  much  the  fingers  disturb  the  trajectory  of  the  ball  during  release.  A 
digital  video  camera  with  the  capability  of  capturing  30  frames/sec  was  used  to  film  the 
arm  during  its  throwing  motion.  Appendix  H  contains  a  selection  of  the  60  or  more 
frames  taken  during  the  arm’s  throwing  motion.  These  focus  mostly  around  the  release 
phase.  Although  the  camera  takes  30  frames  per  second,  the  arm  is  still  moving  fast 
enough  to  blur  and  no  specific  information  about  the  interaction  between  hand  and  ball 
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can  be  derived  from  the  pictures,  at  most  an  estimated  departure  angle  from  the  ball’s 
fairly  linear  blur. 
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8  Conclusions  and  Future  Work 


A  Ball-Throwing  Robot  capable  of  throwing  balls  on  command  to  designated  points 
in  the  room  has  been  successfully  built  and  demonstrated.  The  accuracy  and  repeatability 
of  the  robot  vary  with  distance  and  departure  angle,  but  have  shown  that  departure  angles 
from  10  to  45  degrees  have  the  best  accuracy  and  repeatability 

More  can  be  done  to  improve  the  robot’s  capabilities.  Further  investigation  of  the 
interaction  between  the  hand  and  ball  could  possibly  further  explain  accuracy  variance. 

In  order  to  accomplish  this  a  high  speed  camera  would  be  needed.  Such  a  camera  would 
allow  for  observation  of  the  hand’s  affect  on  the  ball’s  trajectory  during  the  release 
motion.  This  information  is  key  to  determining  exactly  what  is  happening  in  the 
throwing  motion.  For  this  reason  evidence  and  possible  explanations  are  presented,  but 
further  work  is  needed  to  fully  understand  and  hence  fully  control  the  accuracy  of  this 
robotic  arm. 

Another  issue  worthy  of  further  work  and  development  is  the  end-effector  path 
planning.  This  method  of  throwing  could  potentially  be  much  more  repeatable  and 
accurate  than  the  method  current  used. 

Mechanical  design  issues  that  could  improve  the  robot  include: 

1)  Modifying  the  solenoid  attachment  point.  It  currently  forces  the  cable  to 
make  some  awkward  curves.  A  straightened  cable  could  decrease  the 
solenoid  response  time,  allowing  for  more  precise  ball  releases; 

2)  A  larger  gear  on  the  base  axle  would  allow  for  finer  base  angle  control; 
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3) 


The  elbow  shaft  could  be  moved  out,  such  that  the  bouncy  ball  doesn’t  impact 
the  upper  arm;  and 

4)  The  current  motors  have  a  plastic  gear  that  had  to  be  pinned  through  the  shaft 
to  prevent  slipping;  the  metal  gear  on  that  same  shaft  may  need  to  be  pinned 
for  throwing  longer  distances. 

One  area  that  could  increase  performance  in  all  aspects  would  be  further  work  in 
modeling  of  the  system.  A  controller  is  always  limited  by  the  accuracy  of  its  governing 
model.  The  data  on  which  many  of  the  parameters  were  based  had  significant  variations; 
it  may  prove  worthwhile  to  try  using  a  spectrum  analyzer  to  identify  system  parameters 
or  to  build  a  mount  with  which  the  motor  shaft  could  be  clamped,  such  that  the  motor 
inductance  could  be  measured,  in  the  event  that  it  is  affecting  these  results. 

On  this  same  note  this  controller  was  designed  as  something  that  could  be 
implemented  by  the  PK2600.  It  has  not  been  optimized  for  the  system.  There  are  more 
aggressive  but  computationally  demanding  techniques,  which  could  be  done  in  dSpace, 
not  intended  for  use  on  the  PK2600,  which  could  significantly  increase  the  robot’s 
accuracy. 

Other  things  associated  with  the  robot  that  need  to  be  accomplished  include  the 
supporting  web  page  for  high  school  demonstrations.  This  would  include  explanations  of 
particle  dynamics,  air  drag,  bouncing  particles,  and  more  in  depth  information  about  the 
robot. 

This  robot  is  capable  of  many  exciting  demonstrations,  it’s  fast  enough  that  it  could 
potentially  juggle  balls,  get  light  sensors  and  hit  a  light  source  or  any  other  number  of 
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demonstrations  that  could  be  imagined.  Now  that  it’s  built  and  capable,  further 
programming  and  use  of  it  remains,  which  in  many  ways  is  the  funnest  part. 
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Appendix  B  Kinematic  and  Torque  Equation  Derivations 


The  kinematic  and  torque  equations  were  first  derived  by  hand  and  then  checked  using 
Maple.  As  inertial  parameters  were  updated  Maple  was  used  for  quick  recalculation. 
Original  hand  calc’s  and  verifying  Maple  output  are  included.  Free  body  diagram 


included  with  hand  calculations. 


>Position:  =linalg  [matrix]  (2, 1,  [al*sin(thetal (t) )  +a2*sin(thetal (t )  -i-theta2 
(t ) ) , -al*cos (thetal ( t ) ) “a2*cos (thetal (t) +theta2 (t) ) ] ) ; 

al  sin(01(O)  +  ^2  sin(01(f)  +  02(?)) 

-al  cos(01(f))  -  a2  cos(01(?)  +  02(0) 

>Velocity:sinap(di££, Position, t) ; 

Velocity  := 


Position  := 


al  cos(01(O) 


al  sin(01(O) 


(d 


^01(0  |  +  a2cos(01(O  +  02(O) 


(d 


J 

\ 


(( 


^01(0  +a2sin(01(O  +  02(O) 

ot 


dt 

rri 

dt 


01(0 


rd 


^02(0 


01(0 


'  dt 


02(0 


>  Acceleration:  =inap (di££.  Velocity,  t) ; 

Acceleration  := 


-al  sin(01(O) 


'd  V  ( d'^ 

^01(0  +flicos(01(O) 

dt  dt 


,01(0 


-a2  sin(01(O  +  02(O) 


(fd^ 

dt 


01(0 


+ 


'd  \\ 

^02(0 

.  JJ 


+  0.2  cos(01(O  +  02(0) 


'i'll 

^91(0 

V  V  > 

“1- 

^em 

K  J  JJ 

(d 


\ 


aicos(01(O)  ^01(0 

I®'  / 


+  al  sin( 01(f)) 


de 


01(0 


J 


+  0.2  cos(01(f)  +  02(f)) 
+  0.2  sin( 01(f)  +  02(f)) 


((d  \ 

fd  V 

2 

501(0 

VV  / 

+(592(0) 

((?P-  \  ( ;)2  \\ 

+ 

K>| 

CD 

4 


X  ^  -  (6,  f 4)  ^  ^  4 

y  -  f d-f  fe,  1'4)"^25<t  ^ 


::  ^7 


fe,  -<a>.^>. 


r. 


-t 


is  2  2 


x  ■(  ffe,-<e^<i,<„  ■*©,■? 

V  -  (6,^ 


0,  sin(thetal (t) ) ,  cos (thetal (t) ) ,  0,  0,  0, 

1] )&*linalg [matrix] (3,1, [al*sin(theta2 (t) )+a2*siii(thata2 (t)+theta3{t) ) 
0, -al*cos (theta2 (t) ) -a2*cos (theta2 (t) +theta3 (t) ) +baseheigth] ) ) ; 

■  cos(ei(0)  {al  sin(02(O)  +  sin(02(O  +  03(0))  ' 

Position  :=  sin(01(O)  sin( 02( 0 )  +  sin(02(/)  +  03(0)) 

-al  cos(02(^))  -  0.2  cos(02(f)  +  03(f))  +  baseheigth 

>Velocity:=map(diff, Position, t) ; 

Velocity  := 


al  cos( 02(f)) 


If 

fd 


-sin(01(f))|^01(f)  \ial  sin(02(f))  +  a2sin(02(f)  + 03(f))) +  cos(01(f)) 


V 


rri 

dt 


02(f) 


+ 


fd 


03(f) 


^  02(f)  J  +  a2cos(02(f)  + 03(f)) 

cos(01(f))  f ^ 01(f )1  (al  sin( 02(f))  +  a2  sin( 02(f)  +  03(f)))  +  sin(01(f)) 


AW 


V 


J 


al  cos( 02(f))  [  ^02(f)^  +  a2  cos(02(f)  +  03(f)) 


j 


dt 


j 


al  sin(02(f))|  ^02(f) 


+  0.2  sin( 02(f)  +  03(f)) 


I 


^^^02(f)j  +  [^|03(f)^^ 


>  Acceleration:  =inap(diff, Velocity, t)  ; 

Acceleration  := 


-cos(01(f))f^01(f)'' 


-  sin(01(f)) 


|ei(o 


01(f) 


A 


{al  sin( 02(f))  +  a2  sin( 02(f)  +  03(f))) 


{al  sin( 02(f))  +  a2  sin( 02(f )  +  03( f ) ) )  -  2  sin( 01(f)) 


J 


al  cos( 02(f)) 


5^e2(,)j 


cos(01(f)) 


+  a2  cos(02(f)  +  03(f)) 

rd 


dt 


02(f)l  +  f|-03(f)^^^ 


dt 


-al  sin( 02(f))  I  ^ 02(f)  +al  cos( 02(f)) 


V 


J  V 

/a2  A 

^92(0 


J 


+ 


-a2  sin(02(f)  +  03(f))|  I  5- 02(f) 


ffd^ 


+ 


1 93(0^" 


^92(0 


A 


^103(0 

dr 


+  a2  cos( 02(f)  +  03(f)) 

(d  V 

-sin(01(f))  ^01(0  (fli  siii(02(f))  +  a2  sin( 02(f)  +  03(f))) 


+  cos(  01(f)) 


^^91(0 


{al  sin( 02(f))  +  a2  sin( 02(f)  +  03(f)))  +  2  cos(01(f)) 


6 


J 


al  cos(02(O) 
/ 

sin(01(O) 


dt 


^02(0  |  +  a2cos(02(r)  +  03(O) 
2 


ffd 

V 


5j92«) 


+  13^93(0 


-ai  sin(02(?))  3-02(r) 
ot 


rrd 


- a2sin(02(O  + 03(0)  U: 62(0  +  f  03(0 


+  a2  cos(02(O  +  03(0) 


(d 


dt 


+  al  cos(02(O) 
2 


(d 


V 


3,5  92(0 


02(0 


V 


dt 


) 


al  cos(02(O)|^^02(O  +ai  sin(02(O) 


^^63(0^ 


)) 


dt^ 


02(0 


+  a2  sin( 02(f)  +  03(f)) 


f  f  d  \ 

<d  W 

3^92(0 

+ 

vv  J 

ffd^ 

a^ 

3^592(0 

V  V  > 

+ 

5^93(0 

V  JJJ 

''■>  "  t'  ''  ^ 


A  ^ 


'f  '  »n  A  -t  '  ^ 
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■  y/  f 


-■■  yvK  C 

r  t 


*-r'  '  V  '?" 

r  uS^  4  IjlL^  r; 

^  ^  -fi-  / 


f  , -■  X  f  ,aX 

•  «if' 

-  r  "f  u)  K  X  #o 

"If  f  ■  / 

t "  e^  • 


7  •  Tf 
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t>  ^f  ^  "Z- 


R>  ^ 


■  r^- *=  >c  X, 
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ixsi'y, 
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■= ',  dx?^' 
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o  z 


’i"-> 


V,  -,((!l5/^^^<iH  '> 


=  i'll,  ir 

-  -I .  I<2)5  y,'  -f,  '  .  '®7 ►'.j  5in/'A"Aj 

%.^/Si  S)  h^ICbsfjB^  m/ 


5 


-<s 


T;  I  Z^,/a^  4«,^-  ■0l5>^,Ai,-dl5y,  'c4j,) 

'  %•«,•' 2<.-‘^,^  ■-'*'5)^' 


^  •  V) 


'2  / 


~  -^  •  1^ ,  t  7;  '  4J  *^'*^1? "■'  i)'^(i>  K  ‘ ^  ^  '^*.5 '^) 

'  %  *^1  ^  1?  '' @  \  <r  ,<2e^ ^vy ^in  3 

2  'y\  '  ■  > 

-  ^  4 'I<2>T>12^,+ ! 


' .  S]^f9^  i 4 V-*<as3/', ^I3f>^, 

^  .  (2^C>6  *^7  2  5»vn^^ 


,,  * . 

fl 

/ 


X'~ 


\  6  -< 


r  I T 

-.33  ^ 


-,,ii  t.lO’^^,  ‘:‘»&,i’\0. 


l.i.i 


3 


%,,. + 6'»3H '  • 


'l■^ 
9^^ 


:.«4! 


i.j(^,<304y.//>?)  4 


,  /I  til^  I  -".  <5>1,  5  *H_  ^  5J  vl  ^  .  ^X^(p  4  >>i'x-l5j 


r^ 


X,„  +'l®T^  ^,t«5£^+ (.MV,  +  [%,j  +  ( 


^ 


m 


cJy 


I 


Equations  based  on  earliest  inertial  parameters  estimates  from  ProEngineer,  matching 
hand  calculations. 

>cogl:=--0260: 

>cog2:  =  ,105: 

>  zO:=linalg[itiatrix]  {3,l,[0,0^13)s 
>yO:=linalg [matrix]  (3,1/ [0,1,0]): 

>y0  :=  matrix(  [[0]  ,  [1],  [0]]): 

>x0;=linalg [matrix]  (3,1,  [1,0,0]): 

>R01:=evalm(linalg [matrix] (3,3, [cos (thetal (t ) ) ,  -sin(thetal (t) ) ,  0, 
sin(thetal(t) ) ,  cos (thetal (t) ) ,  0,  0,  0, 

1] ) &*evalf (linalg [matrix] (3, 3, [1,  0,  0,  0,  cos(O),  -sin(O),  0,  sin(O), 
cos(O)]))): 

>  R12 ;=evalm(linalg [matrix] (3,3, [cos (theta2 (t) ) ,  -sin(theta2 (t) ) ,  0, 
sin(theta2 (t) ) ,  cos (theta2 (t) ) ,  0,  0,  0, 

1] ) &*evalf (linalg [matrix] (3, 3, [1,  0,  0,  0,  cos(O),  -sin(O),  0,  sin(O), 
cos(O) ] ) ) ) : 

> R02 : -evalm(R01&*R12) : 

> Rl;=evalm(cogl*R01&*x0) ; 

>  R2  :  =evalm(al^R01fii:*x0+cog2*R02&*x0)  : 

> Rld:=map(di££,  Rl,  t) : 

> Rldd:=map(di££,R2d, t) : 

> R2d:=map(di££,  R2,  t) : 

>  R2dd:=inap(di££,R2d,t)  : 

>  omegal:=evalm(di££ (thetal (t) , t) *z0) ; 

>omega2  :=evalm(evalm(di££  (thetal  (t)  ,  t)  *z0)  +evalm(di£f  (theta2  (t) ,  t)  *R01&* 
zO)): 

>  alphal:::::map(di££,omegal,  t)  : 
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>  alpha2:=inap(di£f  ,omega2,t) : 

>  g ; sevalm ( G*xO ) : 

>  fl2;=evaliii(in2*R2dd-m2*g)  : 

>12 ;=evalm(R02&*liiialg  [matrix] (3,3, [ia2, 0, 0, 0, ib2, 0, 0, 0, ic2] ) ) : 

> x2 :=evalm(R02fi:*x0) : 

>  Sx2 :=linalg [matrix] (3,3, [0, -x2 [3,1],  x2[2,l],x2[3,l] , 0, -x2 [1,1],- 
x2[2,l],x2[l,l],0]) : 

>  evalm(omega2) : 

> Somega2 : =linalg [matrix] (3,3, [0, -omega2 [3,1] , 

omega2 [2,1] ,omega2 [3,1] ,0,-omega2 [1, 1] , -omega2 [2,1] ,omega2 [1,1] ,0] ) : 
>nl2:=evalm(R02S*I2&*alpha2+Samega2&*R02&*I2&*caBega2+cog2*Sx2&*fl2) ; 

>torg2 : =sin5)lify (evalm(z0 [1, 1] *nl2 [1, 1] +z0 [2,1] *nl2 [2 , 1] +z0 [3,1] *nl2 [3,1 
])): 


>  evalf ( torq2 , 3 ) ; 

.105  sm(ei(0)  cos(e2(f))  m2  G  +  .105  cos(01(O)  sin(02(O)  m2  G 
+  .105  cos(02(O)wi2  ai  f^01(ol  + -105  m2  sin( 02(f))  a7 


+  .O110m2  -^01(f)  +.O110m2  ^02(f)  +  ic2  z^e2(t)  +  ic2  ^01(0 

[ar  j  J  J 

>  Soinegal:=linalg [matrix]  (3,3,  [0, -omegal  [3, 1]  / 

omegal[2,l] ^omegal [3, 1] , 0, -omegal [1, 1] ^ -omegal [2, 1] ,omegal [1, 1] , 0] ) : 

>  evalm(  omega  1)  : 


>  II :=slinalg [matrix]  (3,3,  [ial,  0, 0, 0,  ibl,  0, 0, 0,  id] )  : 


>  xl :  =evalm(R01&*x0 )  : 

>  Sxl:=linalg [matrix]  (3,3,  [0,-xl[3,l]  ,  xl[2,l]  ,xl[3,l]  ,0,*“xl[l,l]  ,- 
xl[2,l],xl[l,l],0]): 

>  f  01;=evalm(ml*Rldd-ml*g+f  12)  : 

>n01:=evalm(R01&*Il&*alphal+Samegalfi:*R01&*Il&*omegal+cogl*Sxl&*f01+cogl* 
Sxl&*fl2+nl2) : 
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>torqli=siinplify (evalmCzO [1, 1] *n01 [1, 1] +zO [2,1] *n01 [2,1] +zO [3,1] *n01 [3,1 
])): 


>  evalf (torql, 3) ; 


.105  m2  sin(e2(0)  al  ( ^  @1(0  1  +  -105  cos(e2(f))  m2  al  |  61(0 


30 


+  .00454  ml  01(olsin(02(O)  62(0 


\ 

) 


+  .0109  m2 


(d 


) 


\ 


-  .0260  ml  al 


^61(0 
^3^ 


sin(02(O) 


ydt 


.00227  ml 


^  3^ 


+  .01 10  m2 


30 


—  61(0 


30 


-  .0520  m2  al 


30 


f . 


01(0 


+  SmTl  ml  sin(02(O) 


^3  \ 

3,62(0 


+  .0110  m2 

2 


cos(62(0) 


^62(0 


) 


J 


f7\T- 


-.00546  m2  cos(02(O) 


a 


+  .00546  m2  sin(  02(  0 )  3^  62(  0 


+  .00546  m2 


3r 


01(0  sin(02(f))  -  .00546  m2 


30 


61(0 


cos(  02(f)) 


) 


+  .00227  mi  f|-01(f)l  sin( 02(f))  -  .00227  ml  cos(62(f))f^  02(f) 


3f 


J 


3f" 


+  .105  sin(01(f))  cos( 02(f))  m2  G  +  .105  cos(61(f))  sin( 02(f))  m2  G 

^32  A 


-  .0520  sin( 01(f))  m2  G-  .0260  sin( 01(f))  mi  G  +  ic2 


3f 


,61(0 


+  ic2 


\ 


^2  62(f) 

dr 


+  id 


/32 


30 


61(f) 


For  current  parameters; 

>  cogl:  =  .1135: 
>cog2:ss.  08735: 

>  evalf (torq2, 3) ; 
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.00763  m2 


dr 


/;i2 


+  .00763  m2 


dr 


02(0 


+  .0874  sin(01(r))  cos(02(O)  m2  G 


y  v'"  7 

fd  \ 

+  .0874  cos(01(O)  sin(02(?))  m2  G+  .0874  m2  sin(02(?))  al  3-01(0 

I  <2?  j 

/  :i2  \  ^  ;i2  ^  /  02  \ 


+  .0874  cos(02(r))  m2  al 


> evalf (torql, 3) ; 


^91(0 


+  ic2 


ao 


01(0 


+  ic2 


^62(0 


id 


fd^ 


\ 


+  .0874  sin(01(O)  cos(  02(0)  W2  G+. 114  sin(01(O)'n^  G 


J 


+  .227  sin(01(O)  m2  G  +  .0874  cos(01(O)  sin(02(r))  m2  G  +  ic2 


30 


01(0 


+  .0874  m2  sin(02(O)  ^7 


dt 


01(ol  +  .0874  cos( 02(f))  m2  a7 


J 


dt 


/a2 


+  .227  m2  al 


\ 


3f2 


01(0 


+  .00763  m2 


/ 

/a2 


^^92(0 


+  .00991  ml  cos(02(f)) 


^02(/) 

dr 


01(0 


.0198  ml  01(f) j sin( 02(f))  02(f)  j 


(d  \ 

-  .00991  ml  sin( 02(f))  3- 02(f) 

[dt 

(  d^ 

+  .0198  m2  cos( 02(f))' 


dr 


— e2(f)^ 

_  _ r3^  ^ 


-.0198  m2  3- 01(f)  sin(02(f))  +  .O198m2 

at 


.00991  ml 
.0198  m2  sin( 02(f)) 

01(f) 


^^01(f)'|  sin( 02(f)) 


) 

^|e2(,)l 


V 


) 


dr 


y;)2 


+  .00991  ml 

+  .00763  m2 
-  .0397  m2  ^ 


^^91(0 

^91(0 


cos( 02(f))  +  .114  ml  al 
^32  \ 


^3" 

^91(0 


cos( 02(f)) 
A 


J 


+  ic2 


^2  02(f) 

dr 


^01(f)lsin(02(f))f|02(f)^ 
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Appendix  C  Hand  Motion  Calculations 


Appendix  C  contains  Maple  calculations  and  hand  drawn  sketches  in  the  rear  of  the 
appendix  to  illustrate  variables’  meanings. 
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The  purpose  of  this  Appendix  is  to  display  the  calculations  used  in  designing  the  hand.  There  were  a  few 
things  that  needed  to  be  determined  to  validate  the  idea  of  the  solenoid  acuated  hand: 

1)  Can  the  solenoid  move  the  fingers  and  opposing  spring  fast  enough  to  release  the  ball  without  interfering 
with  its  trajectory? 

2)  Will  the  solenoid  have  sufficient  strength  to  hold  the  ball  without  letting  it  slip? 

3)  Will  the  one-inch  of  pull  move  the  fingers  far  enough  to  clear  them  out  of  the  ball’s  path? 

Section  4.7  discusses  these  questions  and  the  following  material  supports  the  discussion. 

Attached  are  sketches,  which  illustrate  the  meaning  of  the  variables. 

See  Sketch  #1 

length  from  pivot  to  center  of  hole  for  ball 

>  a:=1.5s 

length  of  moment  arm  to  which  solenoid  connection  bar  attaches 
>b:=:l: 

distance  pivot  is  offset  from  the  connection  bar's  pivot  at  the  cable 
connection 

>  c:=0.25: 

length  from  moment  arm  connection  to  to  cable  attachment  -  ie  the 
length  of  the  connection  bar 

>  d:=1.5; 

See  Sketch  #2 

length  between  pivots 

>  f  ;  =  (c'^2+y'^2)^.5; 

> 

/:=(.0625+y2)' 


See  Sketch  #3 

angle  between  connection  bar  and  moxaent  arm 
>psi:=arccos( (f ^2“b^2“d^2 ) / (-2*b*d) ) ; 

\|/  :=  7C  -  arccos(. 3333333334  (.0625 


1.0 


-  1.083333334) 


See  Sketch  #4 

emgle  within  the  right  triangle  that  has  the  effective  moment  arm  as 

the  base 

>mu;=Pi“psi; 

|Li  :=  arccos(. 3333333334  (.0625  +y^)  '^  -  1.083333334) 

the  angles  the  connection  bar  makes  with  the  moment  arm  at  the  pivot 
wrt  y  -  linear  displacement 

>plot ( [psi*180/Pi,  mu*180/Pi] ,y=1.2. .2 .2^ label s= ["Displacement 
(in)","Psi  &  Mu  (degrees)"]); 


17 


the  effective  xnoment  arm  wrt  y  -  linear  displacement 
>bpriine:=5b*sin(mu)  ; 

bpritne  := 

> plot  (bprime,y=l  .2 .  .2 ,2#  0  ..  1,  labelsss  [ "Displacement  (in)  "  ^  "Moment  Arm 
Length  (in)"]); 


1.0 


1  -(.3333333334  (.0625  +  /)  -  1.083333334) 


Mechanical  Advantage 

>plot (l^rime/a,y=1.2. . 2.2,0. . 1, labels^ [ "Displacement  (in) ", "Mech 
Adv"] ) ; 


>Xvalues:=[0, .125, .25, .375, .5, .6125, .75, .8725,1] ; 

Xvalues  ;=  [0,  .125,  .25,  .375,  .5,  .6125,  .75,  .8725, 1  ] 

> Yvalues:s[336,220,168,144,142,140,132,120,90] ; 

Yvalues  :=  [336,  220,  168, 144,  142, 140, 132,  120,  90] 

>  with (stats) : 

>  solenoidforce:=£it [leastsquare[ [x,y] , 

y=al*x*5+a2*x*4+a3*x*3+a4*x*2+a5*x+a6,  {al,a2,a3,a4,a5,a6} ] ] ( [Xvalues, 
Yvalues] ) ; 

solenoidforce  :=y  =  -650.9492847  +  2395.128961  ;c^  -  3916.788773 

+  3192.841030  jc^  -  1266.030358  jc  +  335.9386351 

>plot((-650.9492847*x'^5+2395.128961*x''4- 

3916.788773*x'^3+3192.841030*x^2- 

1266,030358*x+335.9386351)/16,x=0. .l,labels=[ "Displacement 
(in) "r "Solenoid  Force  (Ibf)"]); 


Force  Available  wrt  linear  displacement  of  the  solenoid 
>plot((-650.9492847*y^5+2395.128961*y^4- 

3916.788773*y^3+3192.841030*y^2-1266.030358*y+335.9386351)*(sqrt{l- 

(.3333333334*{.625e-l+(y+1.2)^2)^1.0- 

1.083333334) ^2) ) / {a*16) ry=0 . .1, labels= [ "Displacement  (in) " y "Applied 
Force  ( Ibf ) " ] ) ; 
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10 


Applied  Force  (Ibf) 


See  Sketch  #5 

> phi : ssarccos ( (d^2-b^2“f  ^2)  /  (-2*b*f ) )  ; 


(j)  :=  71  -  arccos 


^1  1.25 -( .0625  +y^) 
^  (.0625+/)'^ 


1.0  \ 


See  Sketch  #6 

>  theta :=arctan{y/c) ; 

0  :=  arctan(  4.000000000  y) 


See  Sketch  #7 
>  2eta:=phi+theta; 


^  :=  71  -  arccos 


1  1.25  -  (.0625 

2 


1.0  N 


.5 


+  arctaTi( 4.000000000  y) 


(.0625  +/) 

angular  displacement  wrt  to  linear  displacement 
>plot{zeta*180/Pi,y=1.2.  ,2 .2, labels=  ["Displacement  (in)  ",  "Zeta 
(degrees) "] ) ; 


> 
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Appendix  D  Tree/CoTree  Derivations 


This  appendix  contains  both  the  second  order  and  third  order  system  derivations  of  the 
motor,  ignoring  inductance  and  including  inductance  respectively. 
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Appendix  E  dSpace  Procedures  and  Simulink  Code 


Appendix  E  dSpace  Procedures  and  Simulink  Code 


J2|x| 


2.  Hit  the  Plyform  Tab(GregiR^  under  white  field  at  left  of  screen) 

5te  £dt  ipew  look  Experiment  Plfitform  t»tnjfnentation  ^ndow  ^ 


3. 

4. 


jli2  ♦  CS  B  U-  %  e  1  i  £  1  j  Iff 

Jfssaj 

»  j||ii  •sal 

)  ii  X  1 

jjsi  \  1^  1 

- - - - - - - i^jcj 

1 

-  ^  .  I  iCLfii  i  jnw 

Right  click  on  Simulink  at  top  of  tree  in  white  window  on  the  left  and  select 
“Open  Matlab”  Matlab  will  automatically  load  up. 

In  Matlab,  change  the  working  directory  from  c:\matlabrl2\bin\win32  to  » 
c:\matlabrl2\work\RobArm 


5.  We  have  to  establish  certain  variables  as  global  variables,  so  open  datainit.m  for 
editing,  type  edit  datainit  and  the  Matlab  editor  will  open  up  datainit.m,  there  is 
a  whole  list  of  global  variables  that  must  be  copied  into  the  workspace,  (to  be 
truly  global,  they  must  be  declared  global  in  the  workspace  and  in  the  m  file).  So 
highlight  all  lines  declaring  global  variables,  copy  and  paste  into  the  command 
line,  execute,  then  type  “datainit;”  and  execute  to  initialize  the  variables. 

6.  Go  back  to  the  Matlab  main  window  and  open  Simulink,  then  open  robarmb.mdl. 

7.  To  load  the  code  onto  the  dSpace  processor,  choose  from  the  menu:  Tools,  Real- 
Time  Workshop,  Build  Model. 

8.  Once  loaded  onto  the  dSpace  processor,  then  the  Control  Desk  GUI  must  be 
loaded,  so  return  to  the  Control  Desk  Window  and  open 
“c:\DSPACE\work\RobArm\robarm6.1ay”. 

9.  When  prompted  choose  to  load  data  connections  and  all  the  GUI  buttons  will  be 
tied  to  their  associated  variables  in  the  Simulink  Model. 


-CJ  Readme 

Ii  -OR^kemel  |D  Ami_rti1103  File  Folder 

:  f  CJ  S^  ^IgAnamd  7KB  mdifile 

<  1  >  iNfV  logViwwef  A  1ntefpretef‘7v F**  Setedof  A  c:\wadabr12»wrt{yn>batTnVeban^ 


05/17^1  14:27 


ForHdp,  press  FI, 


At  the  top  of  the  screen  there  are  three  similar  looking  buttons,  directly  to  the 
right  of  a  red  book,  of  these  three  the  left  is  depressed  in  the  picture.  This 
designates  the  GUI’s  editing  mode,  the  middle  designates  test  mode  and  the  right 
button  is  animation  mode.  To  run  the  robot,  press  the  animation  mode  button. 

1 1 .  The  default  data  capture  mode  starts  with  the  animation  for  0.02s  and  repeats.  I 
usually  push  the  stop  button  directly  under  “PPD  -  robarmb  -  Host  Service”. 

12.  Next  I  right  click  on  the  red  and  white  Start  button  and  choose  “Highlight 
Variables”.  This  then  shows  a  red  chain  link  in  the  bottom  right  window  beside 
the  variable  that  the  chosen  button  is  coimected  to.  Now  I  now  that  the  Start 


button  uses  the  variable  “Trigger”.  To  setup  the  data  capture,  click  and  hold  the 
grey  block  that  says  value  beside  the  red  chain  link  and  drag  it  up  to  the  “«Drop 
trigger  variable  here»”  window  above.  This  tells  the  data  capture  what  variable 
to  use  as  trigger. 

13.  Now  to  configure  the  capture.  I  hit  Settings,  and  change  the  attributes: 

a.  I  turn  off  the  auto  start  with  animation 


b.  I  change  the  length  to  3  seconds 

c.  I  then  hit  the  trigger  tab  and  choose: 

i.  “Trigger  on  Signal” 

ii.  the  Rising  Edge  Trigger  button 

iii.  a  zero  second  delay 

iv.  a  level  of  0.5,  hit  apply  and  exit 

14.  Now  I  usually  like  to  get  a  bigger  GUI,  so  I  hit  View  and  FullScreen 


Pre-Throw  Diagnostics 

1 .  I  move  the  base  back  and  forth  to  make  sure  the  computer  is  getting  the  position 


information.  I  move  the  shoulder  and  elbow  individually  too.  If  any  of  these  fail, 
there  is  a  bad  coimection  somewhere  that  must  be  fixed  before  throwing 


2.  I  set  all  joints  at  the  zero  position  I  want  them  to  have  and  hit  the  reset  buttons  for 
each  joint’s  encoder.  Make  sure  that  all  reset  buttons  are  released  and  not 
depressed  before  continuing. 

*  Note  that  in  the  DSpace  GUI  for  some  reason  I  don’t  imderstand,  when  a  button  is 
first  hit,  a  dotted  line  appears  around  it  and  it  isn’t  really  depressed  fully,  when 
clicked  again,  then  it  actually  executes,  this  proves  somewhat  annoying  in  certain 
circumstances.  For  example,  the  first  time  the  start  or  move  buttons  are  hit  to  engage 
a  motion,  the  first  value  of  the  array  is  sent  to  the  controller,  but  the  successive  ones 
aren’t  for  some  reason,  until  the  button  is  hit  again  and  released.  Every  successive 
use  of  that  button  without  using  other  buttons  in  between  uses  will  execute  after  the 
first  click.  You’ll  figure  it  out  after  playing  with  it  for  a  while. 

All  editing  of  the  GUI  must  be  done  in  Editing  Mode,  just  right  click  to  get  all  of  the 
buttons  parameters  for  modification,  etc. 


To  capture  data,  press  the  data  capture  (grey)  start  button  at  the  top  and  then  hit  start, 
let  the  robot  execute  the  throw  and  hit  save,  it’ll  let  you  choose  where  and  by  what 
name  you  save  your  data. 


Never  hit  the  Start  button  after  the  robot  arm  has  begun  a  throwing  motion  until  it  has 
finished  the  throw  and  returned  to  its  starting  position. 

To  use  the  Move  button,  first  choose  a  desired  base  angle  position,  then  hit  the  move 
button  twice  (once  to  highlight  it  and  a  second  time  to  engage  the  movement),  the 
robot  will  move  to  the  desired  position. 

****  After  the  robot  has  finished  its  base  motor  movement,  never  hit  the  Move 
button  again  without  changing  the  desired  position,  it  will  wind  up.  It’s  a  flaw,  but 
dSpace  isn’t  the  platform  that’ll  be  used  in  the  schools,  so  I  didn’t  work  the  bug 
out  **** 

I  put  this  in  last  to  make  sure  the  previous  sections  were  read  first.  The  obvious  part 
is  that  the  power  must  be  on,  the  less  obvious,  but  simple  point  I  wanted  to  cover  is 
that  the  kill  switch  coimects  the  power,  so  the  robot  will  not  move  unless  the  kill 
switch  is  depressed. 

Other  safety  features: 

All  electrical  components  are  protected  by  the  lexan  covers 
A  red  LED  shows  when  there  is  voltage  across  the  capacitor:  Never  open  the  case 
when  the  power  is  or  when  the  capacitor  LED  indicator  is  lit.  First  turn  off  the 
power,  then  push  the  discharge  button  until  the  LED  turns  off,  then  it  is  safe  to 
remove  the  lexan  covers  and  work  with  the  electrical  components.  *****  DO 
NOT  PUSH  THE  DISCHARGE  BUTTON  WHILE  THE  POWER  IS  ON,  IT 
WILL  FRY  -  IT’S  ONLY  SAFE  FOR  DISCHARGING  THE  CAPACITOR, 

NOT  FOR  DISSIPATING  THE  POWERGRID**** 
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0.3048  thtttal  2.35619449 

0.2936  thdta2  1.57079633 


Appendix  G  Overlaid  Response 


Time  (s) 


Model  Based  Controller  vs  Acceleration  Feedback  Controller 


Appendix  H  Video  Capture  Frames 
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Appendix  I  Agilent  Data  Sheets  and  Quadrature  Decoder  Circuit  Diagram 
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Agilent  Technologies 

Innovating  the  HP  Way 


Quadrature  Decoder/Counter 
Interface  ICs 

Technical  Data 


HCTL-2000 

HCTL-2016 

HCTL-2020 


Features 

•  Interfaces  Encoder  to 
Microprocessor 

•  14  MHz  Clock  Operation 

•  Full  4X  Decode 

•  High  Noise  Immunity: 
Schmitt  Trigger  Inputs  Digital 
Noise  Filter 

•  12  or  16-Bit  Binary  Up/ 
Down  Counter 

•  Latched  Outputs 

•  8-Bit  Tristate  Interface 

•  8,  12,  or  16-Bit  Operating 
Modes 

•  Quadrature  Decoder  Output 
Signals,  Up/Down  and  Count 

•  Cascade  Output  Signals,  Up/ 
Down  and  Count 

•  Substantially  Reduced 
System  Software 


Applications 

•  Interface  Quadrature 
Incremental  Encoders  to 
Microprocessors 

•  Interface  Digital  Potentiom¬ 
eters  to  Digital  Data  Input 
Buses 


Description 

The  HCTL-2000,  2016,  2020  are 
CMOS  ICs  that  perform  the 
quadrature  decoder,  counter,  and 
bus  interface  function.  The 
HCTL-20XX  family  is  designed  to 
improve  system  performance 


Devices 


Part  Number 

Description 

Package  Drawing 

HCTL-2000 

12-bit  counter.  14  MHz  clock  operation. 

A 

HCTL-2016 

All  features  of  the  HCTL-2000.  16-bit  counter. 

A 

HCTL-2020 

All  features  of  the  HCTL-2016.  Quadrature  decoder  output 
signals.  Cascade  output  signals. 

B 

ESD  WARNING:  Standard  CMOS  handling  precautions  should  be  observed  with  the  HCTL-20XX  family 
ICs. 


2 


in  digital  closed  loop  motion 
control  systems  and  digital  data 
input  systems.  It  does  this  by 
shifting  time  intensive  quadrature 
decoder  functions  to  a  cost 
effective  hardware  solution.  The 
entire  HCTL-20XX  family  con¬ 
sists  of  a  4x  quadrature  decoder, 
a  binary  up/down  state  counter, 


and  an  8-bit  bus  interface.  The 
use  of  Schmitt-triggered  CMOS 
inputs  and  input  noise  filters 
allows  reliable  operation  in  noisy 
environments.  The  HCTL-2000 
contains  a  12-bit  counter.  The 
HCTL-2016  and  2020  contain  a 
16-bit  counter.  The  HCTL-2020 
also  contains  quadrature  decoder 


output  signals  and  cascade 
signals  for  use  with  many 
standard  counter  ICs.  The  HCTL- 
20XX  family  provides  LSTTL 
compatible  tri-state  output 
buffers.  Operation  is  specified  for 
a  temperature  range  from  -40  to 
+85^^  at  clock  frequencies  up  to 
14  MHz. 


Package  Dimensions 


m™ 


330  ±  0J2& 
<0.130  t  0.010} 

0.76  ±  0.13  _ 

(0.030  ±  0.006) 

0.46  i 
(0.018  i 


0.06  — 
0.002) 


I  0.S1  ±  0.13  t  ^1 
1(0.020  ±  0.006) 


n  r-i  r?i  F-t  i-i  n  r-i  n 

t 

8.35  ±  0.25 
(0.250  1  0.010) 

) 

625  i  025 
(0250  ±0.010) 

p 

PIN  1^ 

7.62  ±  025 _ 

25.91  ±0.25 

19.05  ±  0.25 

(0.300  ±  0.010} 

-  (1.02  ±0.010)  - 

(0.750  ±0.010)  • 

320  ±  0.25 
(0.130  ±  0.010} 

1 - 1 

7.62  ±  0.25 _ 

(0.300  ±  0.010) 


3.30  ±  0.25 
10.130  ±  0.010)  I 


3.30  ±  0.25 
(0.130  ±  0.010) 


2.54  (0.100)  TYP 


0.26  ±  0.06-' 
(0.010  ±  0.002) 


1.52  ±0.13 
(0.060  ±0.005) 


0.46 

(0.018  i  0.002) 


2J64  (0.100)  TYP 


0.25  t  0.06  ' 

(0.010  t  0.002) 


DiniMiiom  ar*  in  miHimatars  (inchas) 


Dimaniiom  art  in  millknelart  (inchai) 


PACKAGE  A  LEAD  FINISH:  SOLDER  DIPPED 


PACKAGE  8  LEAD  FINISH:  SOLDER  DIPPED 


PACKAGE  A 


PACKAGES 


Operating  Characteristics 

Table  1.  Absolute  Maximum  Ratings 

(All  voltages  below  are  referenced  to  Vss) 


Parameter 

Symbol 

Limits 

Units 

DC  Supply  Voltage 

Vdd 

-0.3  to  +5.5 

V 

Input  Voltage 

ViN 

-0.3  to  Vj)D  +0.3 

V 

Storage  Temperature 

Ts 

-40  to  +125 

°c 

Operating  Temperature 

Ta'« 

-40  to  +85 

°c 

Table  2.  Recommended  Operating  Conditions 


Parameter 

Sjmibol 

Limits 

Units 

DC  Supply  Voltage 

+4.5  to  +5.5 

V 

Ambient  Temperature 

TaCII 

-40  to  +85 

“C 

3 


Table  3.  DC  Characteristics  Vdd  =  5  V  ±  5%;  Ta  =  -40  to  85°C 


Symbol 

Parameter 

Condition 

Min. 

Typ. 

Max. 

Unit 

Low-Level  Input  Voltage 

1.5 

mm 

High-Level  Input  Voltage 

3.5 

mm 

Vt. 

Schmitt-Trigger  Positive- 
Going  Threshold 

4.0 

V 

Vt- 

Schmitt-Trigger  Negative- 
Going  Threshold 

IHQIIIII 

H 

H 

Vh 

Schmitt-Trigger  Hysteresis 

2.0 

V 

IlN 

Input  Current 

ViN  =  Vss  or  Vdd 

-10 

1 

+10 

pA 

Voh'25 

High-Level  Output 

Voltage 

Iqjj  -1.6  mA 

2.4 

4.5 

■ 

VoL® 

Low-Level  Output 

Voltage 

Iql  “  +4,8  mA 

0.2 

0.4 

■ 

Iqz 

High-Z  Output  Leakage 
Current 

=  Vss  or  Vdd 

-10 

■ 

+10 

pA 

Idd 

Quiescent  Supply  Current 

ViN  =  Vss  Vdd,  Vq  =  HiZ 

1 

5 

pA 

CiN 

Input  Capacitance 

Any  Inputf^^ 

5 

pF 

Output  Capacitance 

Any  Outputi^] 

6 

pF 

Notes: 

1.  Free  air. 

2.  In  general,  for  any  Vdd  between  the  allowable  limits  (+4.5  V  to  +5.5  V),  =  ^.3  Vdd  Vih  =  0.7  Vdi^  typical  values  are 

Voh  =  Vdd-0.5  V@Ioh=-40hA  and  Vql  =  Vgs  +  0.2  V @  Iql  =  1-6  mA. 

3.  Including  package  capacitance. 


Figure  1.  Reset  Waveform, 
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Functional  Pin  Description 

Table  4.  Functional  Pin  Descriptions 


Symbol 


Pin 
2000/2016 


Pin 

2020 


Description 


''DD 


16 


20 


Power  Supply 


Vss 


10 


Ground 


CLK 


CLK  is  a  Schmitt-trigger  input  for  the  external  clock  signal. 


CHA 

CHB 


7 

6 


9 

8 


CHA  and  CHB  are  Schmitt-trigger  inputs  which  accept  the  outputs 
from  a  quadrature  encoded  source,  such  as  incremental  optical  shaft 
encoder.  Two  channels,  A  and  B,  nominally  90  degrees  out  of  phase, 
are  required. 


RST 


This  active  low  Schmitt-trigger  input  clears  the  internal  position 
counter  and  the  position  latch.  It  also  resets  the  inhibit  logic.  RST  is 
asynchronous  with  respect  to  any  other  input  signals. 


OE 


This  CMOS  active  low  input  enables  the  tri-state  output  buffers.  The 
OE  and  SEL  inputs  are  sampled  by  the  internal  inhibit  logic  on  the 
falling  edge  of  the  clock  to  control  the  loading  of  the  internal  position 
data  latch. 


SEL 


This  CMOS  input  directly  controls  which  data  byte  from  the  position 
latch  is  enabled  into  the  8-bit  tri-state  output  buffer.  As  in  OE  above, 
SEL  also  controls  the  internal  inhibit  logic. 


SEL 

BYTE  SELECTED 

0 

High 

1 

Low 

CNT, 


DCDR 


16 


A  pulse  is  presented  on  this  LSTTL-compatible  output  when  the 
quadrature  decoder  has  detected  a  state  transition. 


U/D 


This  LSTTL-compatible  output  allows  the  user  to  determine  whether 
the  IC  is  coimting  up  or  down  and  is  intended  to  be  used  with  the  _ 
CNTdcdr  and  CNTcas  outputs.  The  proper  signal  U  (high  level)  or  D 
(low  level)  will  be  present  before  the  rising  edge  of  the  CNTdcdr  and 
CNTcas  outputs. 


CNT, 


CAS 


15 


A  pulse  is  presented  on  this  LSTTL-compatible  output  when  the 
HCTL-2020  internal  coimter  overflows  or  underflows.  The  rising  edge 
on  this  waveform  may  be  used  to  trigger  an  external  counter. 


DO 


D1 


D2 


D3 


D4 


D5 


D6 


D7 


15 


14 


13 


12 


11 


10 


19 


18 


17 


These  LSTTL-compatible  tri-state  outputs  form  an  8-bit  output  port 
through  which  the  contents  of  the  12/16-bit  position  latch  may  be  read  in 
2  sequential  bytes.  The  high  byte,  containing  bits  8-15,  is  read  first  (on  the 
HCTL-2000,  the  most  significant  4  bits  of  this  byte  are  set  to  0  internally). 
The  lower  byte,  bits  0-7,  is  read  second. 


14 


13 


12 


11 


NC 


Not  connected  -  this  pin  should  be  left  floating. 
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Switching  Characteristics 


Table  5.  Switching  Characteristics  Min/Max  specifications  at  Vdd  =  5.0  ±  5%,  Ta  =  -40  to  +  85°C. 


Symbol  Description 

Min. 

Max. 

Units 

a 

tcLK 

Clock  period 

70 

ns 

2 

tcHH 

Pulse  width,  clock  high 

28 

ns 

3 

Delay  time,  rising  edge  of  clock  to  valid,  updated  count 
information  on  DO-7 

65 

ns 

4 

toDE 

Delay  time,  OE  fall  to  valid  data 

65 

ns 

5 

Delay  time,  OE  rise  to  Hi-Z  state  on  DO-7 

40 

ns 

6 

tsDV 

Delay  time,  SEL  valid  to  stable,  selected  data  b3d;e 
(delay  to  High  Byte  =  delay  to  Low  Byte) 

65 

ns 

D 

tcLH 

Pulse  width,  clock  low 

28 

ns 

D 

Setup  time,  SEL  before  clock  fall 

20 

ns 

9 

Setup  time,  OE  before  clock  fall 

20 

ns 

10 

Hold  time,  SEL  after  clock  fall 

0 

ns 

11 

Hold  time,  OE  after  clock  fall 

0 

ns 

12 

tRST 

Pulse  width,  RST  low 

28 

ns 

13 

tncD 

Hold  time,  last  position  count  stable  on  DO-7  after  clock  rise 

10 

ns 

14 

IB 

Hold  time,  last  data  byte  stable  after  next  SEL  state  change 

5 

ns 

O 

^DOD 

Hold  time,  data  byte  stable  after  OE  rise 

5 

ns 

■31 

Delay  time,  U/D  valid  after  clock  rise 

45 

ns 

17 

Delay  time,  CNTdcdr  or  CNTcas  high  after  clock  rise 

45 

ns 

18 

Delay  time,  CNTdcdr  or  CNTcas  low  after  clock  fall 

ns 

19 

tuDH 

Hold  time,  U/D  stable  after  clock  rise 

10 

ns 

20 

tones 

Setup  time,  U/D  valid  before  CNTdcdr  or  CNTcas  rise 

tcLK-45 

ns 

21 

tuncH 

Hold  time,  U/D  stable  after  CNTdcdr  or  CNTcas  rise 

tcLK-45 

ns 

Notes: 

1.  tcD  specification  and  waveform  assume  latch  not  inhibited. 

2.  tgs,  tos»  tisH»  k)H  pertain  to  proper  operation  of  the  inhibit  logic.  In  other  cases,  such  as  8  bit  read  operations,  these  setup 
and  hold  times  do  not  need  to  be  observed. 


L _ ] 

M 

- — 

“  \ 

— © - - 

k — © - H 

XXXXX-K-XX^ 

L  .  J 

STABLE  DATA 

Figure  3.  Tri-State  Output  Timing. 


Figure  5.  Decoder,  Cascade  Output  Timing  (HCTL-2020 


HIGH  DATA 
BYTE  STABLE 
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Operation 

A  block  diagram  of  the  HCTL- 
20XX  family  is  shown  in  Figure  6. 
The  operation  of  each  m£gor 


HCTL-.2020  ONLY 


Figure  6.  Simplified  Logic  Diagram. 


Digital  Noise  Filter 

The  digital  noise  filter  section  is 
responsible  for  rejecting  noise  on 
the  incoming  quadrature  signals. 
The  input  section  uses  two 
techniques  to  implement 
improved  noise  rejection. 
Schmitt-trigger  inputs  and  a 
three-clock-cycle  delay  filter 
combine  to  reject  low  level  noise 
and  large,  short  duration  noise 
spikes  that  typically  occur  in 
motor  system  applications.  Both 
common  mode  and  differential 
mode  noise  are  rejected.  The  user 
benefits  from  these  techniques  by 
improved  integrity  of  the  data  in 


the  counter.  False  counts 
triggered  by  noise  are  avoided. 

Figure  7  shows  the  simplified 
schematic  of  the  input  section. 
The  signals  are  first  passed 
through  a  Schmitt  trigger  buffer 
to  address  the  problem  of  input 
signals  with  slow  rise  times  and 
low  level  noise  (approximately 
<  1  V).  The  cleaned  up  signals 
are  then  passed  to  a  four-bit 
delay  filter.  The  signals  on  each 
channel  are  sampled  on  rising 
clock  edges.  A  time  history  of  the 
signals  is  stored  in  the  four-bit 
shift  register.  Any  change  on  the 


input  is  tested  for  a  stable  level 
being  present  for  three 
consecutive  rising  clock  edges. 
Therefore,  the  filtered  output 
waveforms  can  change  only  after 
an  input  level  has  the  same  value 
for  three  consecutive  rising  clock 
edges.  Refer  to  Figure  8  which 
shows  the  timing  diagram.  The 
result  of  this  circuitry  is  that 
short  noise  spikes  between  rising 
clock  edges  are  ignored  and 
pulses  shorter  than  two  clock 
periods  are  rejected. 


8 


Figure  7.  Simplified  Digital  Noise  Filter  Logic. 
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Figure  8.  Signal  Propagation  through  Digital  Noise  Filter. 


Quadrature  Decoder 

The  quadrature  decoder  decodes 
the  incoming  filtered  signals  into 
count  information.  This  circuitry 
multiplies  the  resolution  of  the 
input  signals  by  a  factor  of  four 
(4X  decoding).  When  using  an 
encoder  for  motion  sensing,  the 
user  benefits  from  the  increased 
resolution  by  being  able  to 
provide  better  system  control. 

The  quadrature  decoder  samples 
the  outputs  of  the  CHA  and  CHB 
filters.  Based  on  the  past  binary 
state  of  the  two  signals  and  the 
present  state,  it  outputs  a  count 
signal  and  a  direction  signal  to 


the  internal  position  counter.  In 
the  case  of  the  HCTL-2020,  the 
signals  also  go  to  external  pins  5 
and  16  respectively. 

Figure  9  shows  the  quadrature 
states  and  the  valid  state  transi¬ 
tions.  Chaimel  A  leading  channel 
B  results  in  counting  up.  Channel 
B  leading  channel  A  results  in 
counting  down.  Illegal  state 
transitions,  caused  by  faulty 
encoders  or  noise  severe  enough 
to  pass  through  the  filter,  will 
produce  an  erroneous  count. 


Design  Considerations 

The  designer  should  be  aware 
that  the  operation  of  the  digital 
filter  places  a  timing  constraint 
on  the  relationship  between 
incoming  quadrature  signals  and 
the  external  clock.  Figure  8 
shows  the  timing  waveform  with 
an  incremental  encoder  input. 
Since  an  input  has  to  be  stable 
for  three  rising  clock  edges,  the 
encoder  pulse  width  (ts  -  low  or 
high)  has  to  be  greater  than  three 
clock  periods  (3tcLK)*  This 
guarantees  that  the  asynchronous 
input  will  be  stable  during  three 
consecutive  rising  clock  edges.  A 
realistic  design  also  has  to  take 
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into  account  finite  rise  times  of 
the  waveforms,  asymmetry  of  the 
waveforms,  and  noise.  In  the 
presence  of  large  amounts  of 
noise,  ts  should  be  much  greater 
than  3tcLK  to  allow  for  the 
interruption  of  the  consecutive 
level  sampling  by  the  three-bit 
delay  filter.  It  should  be  noted 
that  a  change  on  the  inputs  that 
is  qualified  by  the  filter  will 
internally  propagate  in  a  maxi¬ 
mum  of  seven  clock  periods. 

The  quadrature  decoder  circuitry 
imposes  a  second  timing  con¬ 
straint  between  the  external  clock 
and  the  input  signals.  There  must 
be  at  least  one  clock  period 
between  consecutive  quadrature 
states.  As  shown  in  Figure  9,  a 
quadrature  state  is  defined  by 
consecutive  edges  on  both 


CHA 

CHB 

STATE 

1 

0 

1 

1 

1 

2 

0 

1 

3 

0 

0 

4 

channels.  Therefore,  tES  (encoder 
state  period)  >  tcLK-  The 
designer  must  account  for 
deviations  from  the  nominal  90 
degree  phasing  of  input  signals  to 
guarantee  that  tES  >  tcLK* 

Position  Counter 

This  section  consists  of  a  12-bit 
(HCTL-2000)  or  16-bit  (HCTL- 
2016/2020)  binary  up/down 
counter  which  counts  on  rising 
clock  edges  as  explained  in  the 
Quadrature  Decoder  Section.  All 
12  or  16  bits  of  data  are  passed 
to  the  position  data  latch.  The 
system  can  use  this  count  data  in 
several  ways: 

A.  System  total  range  is  <  12  or 
16  bits,  so  the  count  repre¬ 
sents  ‘‘absolute”  position. 

B.  The  system  is  cyclic  with  < 

12  or  16  bits  of  count  per 
cycle.  RST  is  used  to  reset 
the  coimter  every  cycle  and 
the  system  uses  the  data  to 
interpolate  within  the  cycle. 

C.  System  count  is  >  8, 12,  or  16 
bits,  so  the  count  data  is 
used  as  a  relative  or  incre¬ 
mental  position  input  for  a 
system  software  computation 
of  absolute  position.  In  this 
case  counter  rollover  occurs. 
In  order  to  prevent  loss  of 
position  information,  the 
processor  must  read  the 
outputs  of  the  IC  before  the 
count  increments  one-half  of 
the  maximum  count  capabil¬ 


ity  (i.e.  127.  2047,  or  32,767 
quadrature  counts).  Two's- 
complement  arithmetic  is 
normally  used  to  compute 
position  from  these  periodic 
position  updates.  Three 
modes  can  be  used: 

1.  The  IC  can  be  put  in  8-bit 

mode  by  tying  the  SEL 
line  high,  thus  simplify¬ 
ing  IC  interface.  The 
outputs  must  then  be 
read  at  least  once  every 
127  quadrature  counts. 

2.  The  HCTL-2000  can  be 

used  in  12-bit  mode  and 
sampled  at  least  once 
eveiy  2047  quadrature 
counts. 

3.  The  HCTL-2016  or  2020 

can  be  used  in  16-bit 
mode  and  sampled  at 
least  once  every  32,767 
quadrature  counts. 

D.  The  system  coimt  is  >  16  bits 
so  the  HCTL-2020  can  be 
cascaded  with  other  stand¬ 
ard  coimter  ICs  to  give 
absolute  position. 

Position  Data  Latch 

The  position  data  latch  is  a  12/ 
16-bit  latch  which  captures  the 
position  counter  output  data  on 
each  rising  clock  edge,  except 
when  its  inputs  are  disabled  by 
the  inhibit  logic  section  during 
two-byte  read  operations.  The 
output  data  is  passed  to  the  bus 
interface  section.  When  active,  a 
signal  from  the  inhibit  logic 
section  prevents  new  data  from 
being  captured  by  the  latch, 
keeping  the  data  stable  while 
successive  reads  are  made 
through  the  bus  section.  The 
latch  is  automaticaUy  reenabled 
at  the  end  of  these  reads.  The 
latch  is  cleared  to  0  asynchron¬ 
ously  by  the  RST  signal. 


Figure  9.  4x  Quadrature  Decoding. 
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Inhibit  Logic 

The  Inhibit  Logic  Section  samples 
the  OE  and  SEL  signals  on  the 
falling  edge  of  the  clock  and,  in 
response  to  certain  conditions 
(see  Figure  10  below),  inhibits 
the  position  data  latch.  The  RST 
signal  asynchronously  clears  the 
inhibit  logic,  enabling  the  latch.  A 
simplified  logic  diagram  of  the 
inhibit  circuitry  is  illustrated  in 
Figure  11. 

Bus  Interface 

The  bus  interface  section  consists 
of  a  16  to  8  line  multiplexer  and 
an  8-bit,  three-state  output 
buffer.  The  multiplexer  allows 
independent  access  to  the  low 
and  high  bytes  of  the  position 
data  latch.  The  SEL  and  OE 
signals  determine  which  byte  is 


output  and  whether  or  not  the 
output  bus  is  in  the  high-Z  state. 
In  the  case  of  the  HCTL-2000  the 
data  latch  is  only  12  bits  wide 
and  the  upper  four  bits  of  the 
high  byte  are  internally  set  to 
zero. 

Quadrature  Decoder 
Output  (HCTL.2020 
Only) 

The  quadrature  decoder  output 
section  consists  of  count  and  up/ 
down  outputs  derived  from  the 
4X  decode  logic  of  the  HCTL- 
2020.  When  the  decoder  has 
detected  a  count,  a  pulse,  one- 
half  clock  cycle  long,  will  be 
output  on  the  CNTdcdr  pin.  This 
output  will  occur  during  the  clock 
cycle  in  which  the  internal 
counter  is  updated.  The  U/D  pin 


will  be  set  to  the  proper  voltage 
level  one  clock  cycle  before  the 
rising  edge  of  the  CNTdcdr 
pulse,  and  held  one  clock  cycle 
after  the  rising  edge  of  the 
CNTdcdr  pulse.  These  outputs 
are  not  affected  by  the  inhibit 
logic.  See  Figures  5  and  12  for 
detailed  timing. 

Cascade  Output  (HCTL- 
2020  Only) 

The  cascade  output  also  consists 
of  count  and  up/down  outputs. 
When  the  HCTL-2020  internal 
counter  overflows  or  underflows, 
a  pulse,  one-half  clock  cycle  long, 
will  be  output  on  the  CNTcas  piR- 
This  output  will  occur  during  the 
clock  cycle  in  which  the  in^mal 
counter  is  updated.  The  U/D  pin 
will  be  set  to  the  proper  voltage 
level  one  clock  cycle  before  the 
rising  edge  of  the  CNTcas  pulse, 
and  held  one  clock  cycle  after  the 
rising  edge  of  the  CNTcas  pulse. 
These  outputs  are  not  affected  by 
the  inhibit  logic.  See  Figures  5 
and  12  for  detailed  timing. 


Step 

SEL 

OE 

CLK 

Inhibit 

Signal 

Action 

1 

L 

L 

1 

1 

Set  inhibit;  read  high  byte 

2 

H 

L 

1 

1 

Read  low  byte;  starts  reset 

3 

X 

H 

1 

0 

Completes  inhibit  logic  reset 

Figure  10.  Two  Byte  Read  Sequence. 


INTERNAL  INHIBIT  SIGNAL 
TO  POSITION  DATA  LATCH 


Figure  11.  SimpliHed  Inhibit  Logic. 
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Figure  12.  Decode  and  Cascade  Output  Diagram. 


Cascade  Considerations 
(HCTL-2020  Only) 

The  HCTLr2020’s  cascading 
system  allows  for  position  reads 
of  more  than  two  bytes.  These 
reads  can  be  accomplished  by 
latching  all  of  the  bytes  and  then 
reading  the  bytes  sequentially 
over  the  8-bit  bus.  It  is  assumed 
here  that,  externally,  a  counter 
followed  by  a  latch  is  used  to 
count  any  count  that  exceeds  16 
bits.  This  configuration  is 
compatible  with  the  HCTL-2020 
internal  counter/latch 
combination. 

Consider  the  sequence  of  events 
for  a  read  cycle  that  starts  as  the 
HCTL-2020’s  internal  counter 
rolls  over.  On  the  rising  clock 
edge,  count  data  is  updated  in  the 
internal  counter,  rolling  it  over.  A 
count-cascade  pulse  (CNTcas) 


will  be  generated  with  some  delay 
after  the  rising  clock  edge  (tcHo)- 
There  will  be  additional 
propagation  delays  through  the 
external  counters  and  registers. 
Meanwhile,  with  SEL  and  OE  low 
to  start  the  read,  the  internal 
latches  are  inhibited  at  the  falling 
edge  and  do  not  update  again  till 
the  inhibit  is  reset.  If  the  CNTCAS 
pulse  now  toggles  the  external 
counter  and  this  count  gets 
latched  a  major  count  error  will 
occur.  The  count  error  is  because 
the  external  latches  get  updated 
when  the  internal  latch  is 
inhibited. 

Valid  data  can  be  ensured  by 
latching  the  external  counter  data 
when  the  high  byte  read  is  started 
(SEL  and  OE  low).  This  latched 
external  byte  corresponds  to  the 


count  in  the  inhibited  internal 
latch.  The  cascade  pulse  that 
occurs  during  the  clock  cycle 
when  the  read  begins  gets 
coimted  by  the  external  counter 
and  is  not  lost. 

For  example,  suppose  the  HCTL- 
2020  count  is  at  FFFFH  and  an 
external  counter  is  at  FOH,  with 
the  count  going  up.  A  count 
occurring  in  the  HCTL-2020  will 
cause  the  counter  to  roll  over  and 
a  cascade  pulse  will  be  generated. 
A  read  starting  on  this  clock  cycle 
will  show  FFFFH  from  the  HCTL- 
2020.  The  external  latch  should 
read  FOH,  but  if  the  host  latches 
the  count  after  the  cascade  signal 
propagates  through,  the  external 
latch  will  read  FIH. 
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General  Interfacing 

The  12-bit  (HCTL-2000)  or  16-bit 
(HCTL-201 6/2020)  latch  and 
inhibit  logic  allows  access  to  12 
or  16  bits  of  count  with  an  8-bit 
bus.  When  only  8-bits  of  count 
are  required,  a  simple  8-bit  (1- 
byte)  mode  is  available  by 

holding  SEL  high  continuously^ _ 

This  disables  the  inhibit  logic.  OE 
provides  control  of  the  tri-state 
bus,  and  read  timing  is  shown  in 
Figures  2  and  3. 


For  proper  operation  of  the 
inhibit  logic  during  a  two-b3rte 
read,  OE  and  SEL  must  be 
synchronous  with  CLK  due  to 
the  falling  edge  sampling  of  OE 
and  SEL. 

The  internal  inhibit  logic  on  the 
HCTL-20XX  family  inhibits  the 
transfer  of  data  from  the  counter 
to  the  position  data  latch  during 
the  time  that  the  latch  outputs  are 
being  read.  The  inhibit  logic 
allows  the  microprocessor  to  first 


read  the  high  order  4  or  8  bits 
from  the  latch  and  then  read  the 
low  order  8  bits  from  the  latch. 
Meanwhile,  the  counter  can 
continue  to  keep  track  of  the 
quadrature  states  from  the  CHA 
and  CHB  input  signals. 

Figure  1 1  shows  the  simplified 
inhibit  logic  circuit.  The 
operation  of  the  circuitry  is 
illustrated  in  the  read  timing 
shown  in  Figure  13. 
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the  inhibit  logic  sequence.  During  the  time  that  OE  Is  high,  the  data  lines  are  tri-seated. 


Figure  13.  Typical  Interface  Timing. 
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Actions 

1.  On  the  rising  edge  of  the  clock, 
counter  data  is  transferred  to 
the  position  data  latch, 
provided  the  inhibit  signal  is 
low. 

2.  When  OE  goes  low,  the 
outputs  of  the  multiplexer  are 
enabled  onto  the  data  lines.  If 
SEL  is  low,  then  the  high  order 
data  bytes  are  enabled  onto  the 
data  lines.  If  SEL  is  high,  then 
the  low  order  data  bytes  are 
enabled  onto  the  data  lines. 


3.  When  the  IC  detects  a  low  on 
OE  and  SEL  during  a  falling 
clock  edge,  the  internal  inhibit 
signal  is  activated.  This  blocks 
new  data  from  being 
transferred  from  the  counter  to 
the  position  data  latch. 

4.  When  SEL  goes  high,  the  data 
outputs  change  from  the  high 
byte  to  the  low  byte. 

5.  The  first  of  two  reset  condi¬ 
tions  for  the  inhibit  logic  is 
met  when  the  IC  detects  a 
logic  high  on  SEL  and  a  logic 


low  on  OE  during  a  falling 
clock  edge. 

6.  When  OE  goes  high,  the  data 
lines  change  to  a  high  imped¬ 
ance  state. 

7.  The  IC  detects  a  logic  high  on 
OE  during  a  falling  clock  edge. 
This  satisfies  the  second  reset 
condition  for  the  inhibit  logic. 
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Interfacing  the  HCTL-2020  to  a  Motorola  6802/8  and  Cascading  the  Counter  for  24 
Bits 
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In  this  circuit  an  interface  to  a 
Motorola  6802/8  and  a  cascading 
scheme  for  a  24-bit  counter  are 
shown.  This  circuit  provides  a 
minimum  part  count  by:  1)  using 
two  74LS697  Up/Down  counters 
with  output  registers  and  tri-state 
outputs  and  2)  using  a  Motorola 
6802/8  LDX  instruction  which 
stores  16  bits  of  data  into  the 
index  registers  in  two  consecutive 
clock  cycles. 

The  HCTI^020  OE  and  the 
74LS697  G  lines  are  decoded 
from  Address  lines  A15-A13.  This 
results  in  counter  data  being 
enabled  onto  the  bus  whenever 
an  external  memory  access  is 
made  to  locations  4XXX  or  2XXX. 
Address  line  A12  and  processor 
clock  E  enables  the  74LS138. 

The  processor  clock  E  is  also 


used  to  clock  the  HCTL-2020. 
Address  AO  is  connected  directly 
to  the  SEL  pin  on  the  HCTL- 
2020.  This  line  selects  the  low  or 
high  byte  of  data  from  the  HCTL- 
2020. 

Cascading  is  accomplished  by 
connecting  the  CNTcas  output  on 
the  HCTL-2020  with  the  counter 
clock  (CCK)  inpu^n  both 
74LS697S.  The  U/D  pinion  the 
HCTL-2020  and  the  U/D  pin  on 
both  74LS697s  are  also  directly 
connected  for  easy  expansion. 

The  RCO  of  the  first  4-bit  _ 

74LS697  is  connected  to  the  ENT 
pin  of  the  second  74LS697.  This 
enables  the  second  counter  only 
when  there  is  a  RCO  signal  on  the 
first  counter. 

This  configuration  allows  the 
6802  to  read  both  data  bytes  with 


Address 

Function 

cxxx 

Reset  Counters 

4XXX 

Enable  High  Byte  on  Data  Lines 

2XX0 

Enable  Mid  Byte  on  Data  Lines 

2XX1 

Enable  Low  Byte  on  Data  Lines 

Read  Example 

LDX  2000 

Loads  mid  byte  and  then  low  byte  into 

STXOlOO 

memory  locations  0100  and  0101 

LDAA  4000 

Loads  the  high  b3d:e  into  memory 

STAA  0102 

location  0102 

a  single  double-byte  fetch 
instruction  (LDX  2XX0).  This 
instruction  is  a  five  cycle 
instruction  which  reads  external 
memory  location  2XX0  and  stores 
the  high  order  byte  into  the  high 
byte  of  the  index  register. 

Memory  location  2XX1  is  next 
read  and  stored  in  the  low  order 
byte  of  the  index  register.  The 
high  byte  of  coimter  data  is 
clocked  into  the  74LS697 
registers  when  SEL  is  low  and 
OE  goes  low.  This  upper  byte  can 
be  read  at_^y  time  by  pulling  the 
74LS697  G  low  when  reading 
address  4XXX.  Figure  15  shows 
memory  addresses  and  gives  an 
example  of  reading  the  HCTL- 
2020.  Figure  16  shows  the 
interface  timing  for  the  circuit. 


Figure  15.  Memory  Addresses  and  Read  Example. 
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Figure  16.  Interface  Timing  for  the  6802/8. 


Actions 

1.  The  microprocessor  clock 
output  is  E.  If  the  internal 
HCTL-2020  inhibit  is  not 
active,  new  data  is  trans¬ 
ferred  from  the  internal 
counter  to  the  position  data 
latch. 

2.  An  even  address  output 
from  the  6802  causes  SEL  to 
go  low.  When  E  goes  high, 
the  address  decoder  output 
for  the  HCTL-2020  OE 
signal  goes  low.  This  causes 
the  HCTL-2020  to  output 
the  middle  byte  of  the 
system  counter  (high  hyte  of 
the  HCTL-2020  counter). 
This  middle  byte,  FFFFH  is 
available  at  (2)  through  (4), 
the  first  time  OE  is  low.  In 
this  example  an  overflow 


has  occurred  and  OE  has 
been  pulled  low  to  start  a 
read  cycle.  SEL  and  OE  are 
gated  to  give  RCK  which 
latches  the  external  high 
byte,  equal  to  OOH.  The 
falling  edge,  of  the  CNTcas 
signal  counts  up  the 
external  counter  to  OOOIH. 

3.  With  the  first  negative  edge 
of  the  clock  after  SEL  and 
OE  are  low  the  internal 
latches  are  inhibited  from 
counting  and  the  6802  reads 
the  high  b3d;e  in. 

4.  OE  goes  high  and  the  data 
bus  goes  into  a  high 
impedance  state. 

5.  OE  is  low  and  SEL  is  high 
and  the  low  byte  is  enabled 
onto  the  data  bus.  The  low 
byte  is  valid  through  (7). 


6.  With  the  first  negative  edge 
after  OE  and  SEL  go  high, 
the  first  of  the  two  HCTL- 
2020  inhibit  reset  conditions 
is  met  and  the  6802  reads 
the  low  hyte  in. 

7.  The  data  bus  returns  to  the 
high  impedance  state,  when 
OE  goes  high. 

8.  With  the  first  negative  edge 
of  the  clock  after  OE  goes 
high,  inhibit  reset  is 
complete. 

9.  With  the  positive  going  edge 
of  the  clock,  G  is  asserted 
and  the  external  high  byte, 
OOH  is  available  on  the  data 
bus  from  9  through  10  and 
the  6802  reads  the  high  hyte 
in  at  (10), 


Interfacing  the  HCTL- 
20XX  to  an  Intel  8748 

The  circuit  shown  in  Figure  17 
shows  the  connections  between 
an  HCTL-20XX  and  an  8748. 

Data  lines  D0-D7  are  connected 
to  the  8748  bus  port.  Bits  0  and  1 
of  port  1  are  used  to  control  the 
OE  and  SEL  inputs  of  the  HCTL- 
20XX  respectively.  TO  is  used  to 
provide  a  clock  signal  to  the 
HCTL-20XX.  The  frequency  of  TO 


is  the  crystal  frequency  divided 
by  3.  TO  must  be  enabled  by 
executing  the  ENTO  CLK 
instruction  after  each  system 
reset,  but  prior  to  the  first 
encoder  position  change.  An 
8748  program  which  interfaces 
to  the  circuit  in  Rgure  17  is 
given  in  Figure  18.  The  resulting 
interface  timing  is  shown  in 
Figure  19. 
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*  NOTE:  PIN  NUMBERS  ARE  DIFFERENT  FOR  THE  HCTL>2020. 
Figure  17.  An  HCTL>20XX>to>lntel  8748  Interface. 


LOC 

Object 

Code 

Source 

Statements 

Comments 

000 

99  00 

ANLPl,  OOH 

Enable  output  and  higher  order 
bits 

002 

08 

INS  A,  BUS 

Load  higher  order  bits  into  ACC 

003 

A8 

MOVE  RO,  A 

Move  data  to  register  0 

004 

89  02 

ORL  PI,  02H 

Enable  output  and  lower  order 
bits 

006 

08 

INS  A,  BUS 

Load  order  bits  into  AC 

008 

A9 

MOVRl.A 

Move  data  to  register  1 

009 

89  03 

ORL  PI,  03H 

Disable  outputs 

OOB 

93 

RETR 

Return 

Figure  18.  A  l^pical  Program  for  Reading  HCTL-20XX  with  an  8748. 
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Actions 

1 .  ANL  PI ,  OOH  has  just  been 
executed.  The  output  of  bits  0 
and  1  of  Port  1  cause  SEL  and 
OE  to  be  logic  low.  The  data 
lines  output  the  higher  order 
byte. 

2.  The  HCTL-20XX  detects  that 
OE  and  SEL  are  low  on  the 
next  falling  edge  of  the  CLK 
and  asserts  the  internal  inhibit 
signal.  Data  can  be  read 
without  regard  for  the  phase  of 
the  CLK. 

3.  INS  A,  BUS  has  just  been 
executed.  Data  is  read  into  the 
8748. 

4.  ORL  PORT  1,  02H  has  just 
been  executed.  The  program 
sets  SEL  high  and  leaves  OE 
low  by  writing  the  correct 
values  to  port  1.  The  HCTL- 


20XX  detects  OE  is  low  and 
SEL  is  high  on  the  next  falling 
edge  of  the  CLK,  and  thus  the 
first  inhibit  reset  condition  is 
met. 

5.  INS  A,  BUS  has  just  been 
executed.  Lower  order  data 
bits  are  read  into  the  8748. 

6.  ORL  PI,  03H  has  just  been 
executed.  The  HCTL-20XX 
detects  OE  high  on  the  next 
falling  edge  of  CLK.  The 
program  sets  OE  and  SEL  high 
by  writing  the  correct  values  to 
port  1.  This  causes  the  data 
lines  to  be  tristated.  This 
satisfies  the  second  inhibit  and 
reset  condition.  On  the  next 
rising  CLK  edge  new  data  is 
transferred  from'the  counter  to 
the  position  data  latch. 


Additional  Information 
from  Agilent 
Technologies 

Application  briefs  are  available 
from  the  factory.  Please  contact 
your  local  Agilent  sales 
representative  for  the  following. 
M027  Interfacing  the  HCTL-20XX 
to  the  8051 

MO  19  Commonly  Asked 

Questions  about  the  HCTL- 
2020  and  Answers 
M020  A  Simple  Interface  for  the 
HCTL-2020  with  a  16-bit 
DAC  without  Using  a 
Processor 

M023  Interfacing  the  MC68HCII 
to  the  HCTL-2020 
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